Outside of that, there's the 'warm fuzzy' from others using your code, it's nice to be part of a wider solution and not just the small world of day-to-day coding. It also forces you to project the best version of you, and make sure you've really got something to say, especially when a project serious gets traction. This helps personal development as an engineer, but also as a diplomat ;)
If you're contributing to someone else's repo then know that effort from contributors is in itself motivating for the maintainers. Knowing that people care enough to get involved helps enormously. Granted, not every contribution is always of the quality needed, but still, on balance I think it is still great when others get involved and helps the project push on.
A nice side-benefit that's come along recently is the Github 'Arctic Code Vault' Archive Program [2]. It's good to have my projects be a small part of permanent history (well, at least a millennium!).
It isn't all fun and games, it can be a real drag at times. The amount of time I've spent on my open-source projects is enormous (which is also why you should build something you need). A project that gets a decent level of popularity will require regular effort to maintain both the code and the relationship with your community.
Ultimately though I think it's a rewarding experience, and one that I wouldn't undo.
On the contrary, the ability to find everything you need lowers the motivation :)
I've made contributions to things that benefit me, mostly, e.g., if I'm working on a side project that uses a library, and during that, I notice a bug in the library. If it's simple enough to be fixed, then my side-project benefits. Sometimes, I just report the bug, of course. (Which I count as a contribution; especially a well-written bug report, containing the right level of detail to allow someone to track down a bug is a contribution. A badly written "it broke", not so much, ofc.…)
> I could not just approach my employer and ask if I could help code this open source project.
Most often, it's "this bug is bothering us, we've written a fix, and the cost of upstreaming the fix is < the cost of maintaining a fork." Good managers I've had readily understand that ROI/cost trade-off is to their benefit there; forks are terribly time-consuming. (And it's not something that's going to be the company's secret sauce, of course. But I've never had that happen… the bug fixes that crop up are almost always of the "mundane bullshit" variety, stuff you just want out of our way — which is precisely why they should be upstreamed.)
It is in my best interest to send my changes to the library maintainer so that i do not have to maintain my own fork of the library.
It is not always in best interest of maintainers to merge my changes because it is either more work for them or their purposes for the library are too different from mine.
Maintaining an open source project is a lot of work and i would also like to hear more from maintainers about their motivation to do it.
Also sometimes I write something for myself, then think it's possible someone else might find it useful, so I release it as FOSS on say Github. Later I see people watching it, starring it and forking it, and even adding commits to their forks, so I figure someone else must have found it useful.
* Answering a question about PostgreSQL configuration files on Stack Overflow contributes to the PostgreSQL project.
* Tweeting about your favorite underrated Vim keybinding contributes to the Vim project.
* Supporting Jason Donenfeld on Patreon contributes to the Wireguard project.
* Proofreading the Linux kernel documentation contributes to the Linux project.
* Contributing a translation of the Blender GUI into a less common language contributes to the Blender project.
* Designing a wallpaper artwork for the Plasma desktop contributes to the KDE project.
* Writing a detailed bug report for a Sway crash contributes to the Sway project.
And so on, and so forth.
I've open sourced multiple (small) changes I've made to various open source projects on company time. Usually it's projects we use and where I've either fixed bugs or added a small feature that we could use.
Employer doesn't have to apply patchsets to our dependencies and doesn't have to keep them up to date. Everyone else gets the fixes as well. => Everyone wins. Employer sees that.
Supplying a patch, giving feedback for issues, is the least I can do to give back to the people who took the time to write that code.
Because some projects I contribute to are also relevant in my day job I get a deeper insight into that part. Money/financial aspects do not play into that decision but I'd be twisting the truth if I didn't admit the positive impact FOSS had to my career.
Having contributed to FOSS projects in a public way also says something about the person I'm interviewing. If most of my stack is built on FOSS and an applicant comes along with a cool CV but has not one contribution to a single project it's immediately a hard pass from me. I never put applicants through silly technical screening sessions unless they are fresh outta university. But no public commits are a red-flag for senior engineers.
The lack of public commits does not signal whether or not someone is a competent senior engineer.
Everyone appreciates guides about integrating various tooling with other tools, and there's a lot of decent work to be done in this area.
I also like to use the opportunity to hone my writing skills. I haven't written too many guides, but the most popular one is a POC on using playwright to create simple tests. It still gets a modest amount of views per day, 20-30. I also get a kick out of seeing my work linked within a Microsoft project. Always brings a smile out of me.
> Why do you do it?
Because I can so, why not?
Sometimes the help offer has been enthusiastically accepted, other politely refused (I don't have any problem with that) and sometimes I never received an answer.
So my advice would be to try the waters first, before to start spending time or talking with your boss, and contact the maintainers. Some open source teams are more open to external help than other. Some have a hard nucleus and are wary of introducing a foreigner in the team (probably a wise move), and sometimes people just move on with their lives and forget about their single person home project. You could find also that the contact emails are obsolete and need to research and use a different one.
And if you don't feel comfortable with the team or the project direction after a reasonable period of time, just quit. Don't start a war by leadership, or boycott or badmouth anybody, just detach yourself gradually and move on to other personal projects. Is as simple as that. You are not marrying anybody.
Expecting to get paid for your first contributions to open source sounds, to me, like the wrong motivation.
I use Linux and most s/w I've installed are free and open source. Also, not software as such, but I've benefitted a lot from free programming learning resources.
So, I try to pay it forward similarly by answering questions on stackoverflow/reddit/etc, giving away free copies of my ebooks, open sourcing s/w I've written, promoting open source, etc.
See also: https://opensource.guide/how-to-contribute/ - section 4 has handy links to find projects
I've used open source whenever possible for a long time but never "gave back". It was a matter of finding the right thing to contribute to. When I found and used SolveSpace, I loved the tool but found it a bit limited in capability. Looking at the dates on the repository I found that the areas I thought needed work hadn't been touched in at least 2 years. Then I realized if I wanted it to be better it's my job to make it so. It's still the only project I really contribute to, but there are a couple others I may get involved in at some point. I no longer have a lot of time for programming as a hobby, so I view this as me doing volunteer work. It's a bit of responsibility I've decided to take on at least as much as it is a fun thing.
Your reasons for doing and your choice of project will be your own.
- I simply don't know where to begin... which one to contribute to? I don't have an area of computing that excites me to such a degree for longer than a week.
- I worry that anything meaningful that warrants open-source contribution is going to established - and will feel more like a dayjob in terms of creativity (or lack thereof; implementing a shopping list of FRs) and formality.
I could be entirely wrong but I've never tested this hypothesis as I have a huge backlog of (useless/unprofitable) side-projects to build. Perhaps I'm more of a lone wolf :)
EDIT: One thing that I do assume would be better in established OS is focusing on complexity and going deeper. With side projects you'll often spend far more time on boilerplate stuff than on the "big idea" that might have drawn you in.
Now that I'm working full-time on open-source and my own company I can contribute more easily to projects like upgrading SQLite source in a few bindings libraries [0], [1], [2] when 3.38 came out.
If anyone is interested in contributing to open-source and wants a bit more guidance though I have a number of good "first timer" projects related to data tooling for [3]. Only expectation is that you have some experience with Go. Join discord.multiprocess.io, go to the #dev channel and say hi!
[0] https://github.com/mattn/go-sqlite3/pull/1019
[1] https://github.com/mapbox/node-sqlite3/pull/1550
The idea is to put together a project that gives an overview of how to set up a minimal viable web application from scratch via all the different frameworks.
For each framework the project features a self-explanatory shell script that builds a web app with routing, templates and user accounts. So there is no ambiguity of how to reproduce the results. And it is even possible to just copy&paste the steps into a fresh Linux installation, see the framework in action and build your own application on top of it.
The scripts have one part for every aspect like routing, templates, accounts. So if you want to compare how the frameworks do templating, you can look at the "Let's use templates" part and have a quick overview of how it is done in Django, Laravel, Flask, Symfony, NextJS...
So far, 5 developers have joined and contributed. Django and Flask are complete. Laravel and Symfony have routing and templates but no user accounts yet. I wonder if this distribution of contributions across the frameworks is somehow telling about their ecosystems?
Here is the repo:
My motivation to do so is if everyone puts in just a little bit of extra effort to contribute upstream we can get many people making small patches. It's nice for a contributor to see folks care (as opposed to just complaining of issues).
I try to use entirely free and open source software on my personal laptop (and I'm fortunate enough that my work environment is fairly similar too).
When I encounter some kind of annoying issue, I'll take a look at the code that caused the problem (and sometimes the components that it interacts with), and if there's a way to improve the situation then I'll consider putting together at least an issue report.
In practice the time and thought required to write a code-level description of the problem can sometimes be 90% of the work to develop a fix, so frequently the issue report is followed swiftly by a patch / pull request / merge request.
Review, merge and release can all take time - at various points I've had over twenty changes pending to more than ten separate projects.
It's extremely satisfying and encouraging to wake up or check your email and be reminded about some kind of nagging bug/problem that you encountered months or even years ago and to hear that it's now solved for you and anyone else who would have run into the same issue in future.
A suggestion, although everyone can learn in their own way: consider treating open source contributions the same way that you might do for small tickets or tasks at work.
To me, contributing to OSS for 'community' brownie points never had any meaning, mainly because it sometimes skews the perception of actual interest in a project with interest of a person to be recognized by contributing to that project.The latter is a legitimate goal, but most people are not coming forward with this aspect.I don't recommend entering OSS contributions if you're not comfortable with financial risk.It sounds cliche but it's true: OSS contributions and activity should not be influenced by money, but rather (and it still often is) mainly by actual interest: hobbyists, researchers, etc.However this is not a fairy tale and things still get moved by money: it's just a matter of priority and where do you see the value.
There are two ways I could see contributing more. One is by creating some libraries that would hopefully be used by others. This is something I'm definitely trying to push myself to do, which includes gaining some confidence of just getting something out there. The other way is to contribute to existing projects, but I have personally found this difficult. Code bases are often extremely complex, and I personally just don't understand how some people are able to dive into foreign code bases and be productive. It's possible I'm not smart enough, but the other excuse is that there's often a lot of documentation missing or nonexistent and it's tough to get some mentoring on things since everyone else contributing is already so busy.
I've just recently started doing it, and I only put in a few hours each week. Slow and steady wins the race. My motivation is three-fold: First, it's gratifying to give something back to software I love using for free. Second, I learn a lot. Third, if I ever want to work with one of the companies who are stewarding these repos, it gives me a leg up in the application process.
0: https://github.com/owid/owid-grapher
1- I use the app and wanted to give back something.
2- I use many open source software and wanted to help a small open source tool.
3- Practice my coding skills on a open source project.
It does require some commitment from your part but you can help with small things that don't require a lot of your time, like writing documentation, translating, testing. You can commit maybe 1hr a day/week to write/translate documentation, or test a bug someone fixed.
I started doing translations because it was simple enough for me to begin understanding the projects processes and the code.
Also, it feels good that you are helping the project continue and be used by other people like you even if they don't contribute.
If you're using open source and inevitably find bugs or missing features start with opening good and thorough issues for them. That's already a (minor) contribution that is more often appreciated than not. Then ask if the maintainers are open to accept a PR for the issue and if they say they are go on and do the work. Expect feedback and criticism on the PR and respect that it's the maintainers that have to deal with your contribution once it's merged.
If you do all that in a respectful manner, it usually will be appreciated and you will have given something back.
Another option is to just start your own project if you encounter something that is missing, possibly during your job, and get permission to open source that.
I maintain a couple open source projects and one of them solved a business need for my employer back then. I asked permission and got clearance to contribute my work to open source.
The project solves a rather small very specialized problem that any other option didn't sufficiently. I had initially written it to replace a central part of another open source project that was just way to inefficient. Instead of just adding the code there, I created a standalone library that then got used by that project. That way I was putting less burden on the maintainer of the bigger project by reducing his code base and taking over that part in a separate project. As it was also open source he could always fork it and adjust if necessary and the change was completely compatible with previous versions, just that it was two orders of magnitude more performant. On top of that others could use my project standalone if they only required that functionality.
By now it's multiple years old, has been downloaded nearly 10 million times, requires nearly no support (it's that simple), has less than 10 stars on Github, but is used in hundreds of projects on Github.
Of course, I'm proud of it and I consider it a success story of open source without too much sustained effort.
Ask your employer if you can submit documentation or a patch to a project if you notice a bug. It's unlikely they would say no as long as it contains no proprietary information. You can give them a whole pitch about how open source is free software that somebody else maintains, and that you contributing a fix is much cheaper than you having to maintain your own private patches and apply and fix them every time the software is changed upstream. It's saving them time and money. It also gives your company a better reputation among hackers, making it easier to hire good people.
I wrote code for money before. I loved the work, hated the environment, didn't believe in the product. I would do it again, only if I had to. I'd rather work at a gas station.
My motivation is to use what skills I have to enact changes on the world I'd like to see happen, no matter how small. It's not much, you won't catch me maintaining a logging library or something like that, usually it's little tools for people to use.
I'd like to contribute more, given how much I use open source software. It's really hard to keep writing code after a day spent writing code for work.
And before I made money from open source, I always did it with the (very tiny) hope of making this a full-time job. Basically I created a dream job for myself. (Of course this wasn't easy and isn't for everyone as this took a long time, talented other people, luck, hard effort, more good than bad decisions, ...)
> I could not just approach my employer and ask if I could help code this open source project.
Why not? (Your chances are probably higher, when the project is related but still you should try.)
But isn't part of the thesis of capitalism that it should drive market efficiencies and thus reduce the cost of goods and services for consumers?
(that could have sounded tongue-in-cheek; it's not intended to be. as I genuinely understand it, cost reductions over time are supposed to be one of the benefits of the free market system. and if those savings are being achieved thanks to open source software in industry -- which I believe they are -- then I think it's worthwhile questioning the effects. do profit margins and tax burdens increase accordingly with the efficiency savings, for example?)
Depends on what your skillset is, you can help add and/or improve docs, design a logo/swag/icon, author a blog post about your experience with the project, etc.
Sharing a tweet for inspiration: https://twitter.com/DynamicWebPaige/status/10968202457155051...
Why not? Every open source contributor I know is because we worked together and they got paid to write open source software that was valuable to the company.
I know many do it outside of work and my sample set is certainly biased, but I also know that a lot of companies will pay for it if they use that software and see value in it getting better.
Certainly doesn't hurt to ask!
..sort of. I'm sure I could make time if I were determined enough, but it's hard to feel good about spending 8+ hours working in front of a screen, then spending more hours working in front of a screen for free. It's probably more of a mental + physical health concern than anything else.
I don't know how you can avoid doing it at all, unless you're just messily working around issues in your codebase or leaving a TODO or item in the backlog to fix it in the distant future. (Which can be a better use of time sometimes of course.)
My motivation is saving others the ass-ache I just went through. There’s no reason in my mind that I should have a fix and not share it, especially after all of the lift/savings I've gotten over the years from emacs, Linux, apache, svn, git, etc.
I program for the joy of it. My dad got me a Commodore 64 when I was little. Later I had an IBM XT PCjr. I read Abrash's black book and wrote Wu anti-alias line drawing routines in assembly using DOS debug. ( https://en.wikipedia.org/wiki/Debug_(command) ) It was brutal and I loved it.
I encountered "The Next Whole Earth Catalog" and learned about Christopher Alexander (Pattern Language), Bill Mollison (Permaculture), and Bucky Fuller (Design Science Revolution), among others, and I developed a vision of a different, better world, where drudgery was eliminated by science and technology.
To me software is really only important as a means to this end, and charging for copies of it adds unnecessary and even regressive friction.
> coding without pay is so foreign to me
Ha! I wrote software for about a decade before getting a job doing it. I had been homeless for several years and got tired of e.g. not having a refrigerator or indoor plumbing, so I whumped up a project, presented it at CodeCon 2004, and was hired for my first real computer job later that day. (I'm still messing around with that project BTW: https://xerblin.readthedocs.io/en/latest/index.html )
I should mention that computers can also serve as a kind of spiritual investigation tool, but that's really only for folks on what is called the "mind-only" path.
Anyway, to sum up: to me FOSS is only important as a way to transform economic paradigm to a better. more humane world. Otherwise you're just automating this current shitty system, and "Where's the fun in that?"
So, maybe I was lucky the plan worked, but it was not just a coincidence.
BTW, that company is still in full hiring attitude, in case you like working on free software.
nixpkgs' issue tracker has helped (and taught!) me a lot of things :)
All the better if the issue leads to a PR by me or someone else :D
I write my web apps with Nim on the back-end and Flutter on the front-end. The release will also feature a Python SDK.
Why? First of all I like software with less bugs, so that's what I tend to do, all my greenfield development usually happens in my own toy projects. One of the reasons is that I don't have to think about long-term quality and getting it exactly right, like at $dayjob (mostly for architectural decisions, obviously I try to fix the bugs properly...).
A smaller part is also just giving back. I've profited immensely from open source stuff over the last 24ish years, including most of my income in the first years.
That said, I also take extensive breaks. If I don't feel like coding outside of work for a few months, I won't - that's also one of the reasons I am not interested in leading a bigger project, although just doing some releases or merges and bugfixes once in a while is perfectly fine.
I don't think anyone must feel pressured to contribute to the greater open source system, but I absolutely ask any 'bystanders' that they're not entitled to anything, including prompt replies or bugfixes - but if I see that a prolific open source contributor has a problem I might be expediting that issue. (Yes, I might be doing the meritocracy thing wrong :P)
Regarding "at the workplace" - sadly it diverges greatly from employer to employer. I had jobs where there was no question whether I get a day to investigate a bug and properly repro and report it upstream (or do a fix), and others where it was more like "no you can't do that" (and then sometimes I fixed it at night on my own time, but rarely) and many in between. But in my experience it's usually in the company's best interest if the developers understand the things they depend on and have familiarity with the code base, so upstreaming stuff should be a nobrainer... so it has mostly worked out for me.
As long as your work is clean, understandable, and approachable, not having some long-tail back story or 'real identity" is completely fine.
Way easier to ask for forgiveness than permission. Just do it as long as it’s somewhat relevant to your job.
More seriously; no. The license gives no warranty for the software, or potential issues I encounter. If the developer would take more professional responsibility there, I might feel like funding or contributing somehow. But if their approach is this is free stuff no strings, my approach is freely take and provide no guarantees in return.
Was it the use of “more”?
Do such folks have some indelible claim to the premise and conclusion and a monopoly on refusing to go further for others?
I did nothing but establish my line in the sand is similar to theirs. If you’re hurt by it, find a therapist.
