51–60 of 84 posts
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!
> 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.
The best motivation is a need for yourself or your job. 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…
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.
Like everyone else i rely on open source libraries. I sometimes need to change them either to fix bugs that i encounter or to improve them in some way to better fit my purposes. 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…
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.
Build it 'cos you need it. The things I have open-sourced I need/needed. The motivation then is clear. 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.…
* 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.
Build it 'cos you need it. The things I have open-sourced I need/needed. The motivation then is clear. 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.…
Awesome answer thanks! Can I follow you on GitHub.
Build it 'cos you need it. The things I have open-sourced I need/needed. The motivation then is clear. 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.…
On the contrary, the ability to find everything you need lowers the motivation :)