41–50 of 84 posts
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.
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.
Earlier quoted context omitted.
Yes
the point I'm trying to make is that open source is already the status-quo today. calling it a movement makes it sound like it might not be here to stay. movements come and go but open source is _the_ natural state for a SW to be in. the times when we had to battle Microsoft on ideological grounds on their claims that FOSS is a problem are long gone. Nobody at Microsoft today would claim that FOSS isn't here to stay…
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.)
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.)
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.
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.
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.
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.