Why don't more developers contribute to open source?
timkellogg.me
timkellogg.me
Or, alternatively, we could speed its demise. (Disclaimer: I'm massively speculating here.)
Brooks's Law applies to open source projects, too. As the number of people working on a project increases, so does the amount of time more-experienced project members have to spend on supporting less-experienced project members (giving advice, evaluating their changes, fixing their bugs, etc.). So does the amount of time that can be eaten up by communication in general. That creates a succession of traps:
- Project maintainers can get caught spending all their time doing the unfun bits (bureaucracy) instead of the fun bits (cutting code).
- By extension, more coding work has to fall to contributors who are theoretically less productive at the task.
- At some point, this results in each new contributor being a net negative in terms of productivity.
- Meanwhile, the core team members are getting bored or frustrated or both, and burning out.
I'm thinking here, too, of that recent study suggesting that 40-person teams are approximately as productive as 4-person teams. Speaking from my own experience, I suspect that the team that's 1/10 the size is also having 10x as much fun.
So I suspect that a project is generally much better served by a few people who work on it because they are really dedicated to it, than by a large number of people who make small contributions, perhaps only out of a sense of obligation. Sure, the vast majority of developers are most likely just consumers of open source tools and not producers of it. That's ultimately a good thing. If everyone's making bricks, who's left to build walls?
I've had some projects that I've never released as Open Source because it's a lot of work. The success of things I have Open Sourced has been entirely dependent on additional effort I've put into documentation and fit-and-finish... Sometimes these efforts are 2x the cost of developing something that was "good enough for me"
I can't say it's a good thing, but it's common for a company that develops commercial software to require several days to set up a build environment for a new developer. If you've only got, say, 5 developers, the burden is tolerable and companies choose to live with this rather than take the effort to create a reproducable build system. (And no, a virtual machine doesn't count)
An Open Source project, however, really needs to be something that builds and works out of the box and that has complete documentation as to how to do it.
The level of fit-and-finish work to get there is similar, but different, from the work required to make a successful commercial product. Except there's no pot of gold at the end of this rainbow -- and as this article points out, working for free is one of the best ways to experience burnout.
On top of that, code you release is like a puppy. Odds are you'll have users who want support long before you have any help in development. You might find, 8 years after you release it, that you got one of the coefficients wrong in a random number generator -- and then you feel a strong moral obligation to update the software even when it was written in an environment you haven't used for 5 years.
So you might think you like like a hero now for releasing some fresh code on github, but later on you're the monster who dumped out a lot of garbage years ago.
This has sometimes included a crap/missing build system, although it is important (if people can't use it they're unlikely to care).
I have contributed to open source before. I often have time/energy to write the original patch, but not enough to write tests and whatnot. Rather than feeling good about my contribution, I typically feel guilty about not supporting the change as much as I should. That feeling of guilt leads to hesitation every time I see an opportunity to contribute.
tl;dr: laziness
I only got this pretty recently. For the longest time, something did not work, I would try to look for an obvious cause but more often than not, I would not find anything and just give up.
More recently though, I observed myself quickly finding the code in question and usually am able to figure out the issue, too. From there, you can see how much effort it would be to fix it. This is amazingly awesome! I absolutely love it!
It really devaluates closed source software for me. If something in Matlab or Cocoa is broken, tough luck for me. If it's broken in Numpy or Qt, I can deal with it and either circumvent it or directly fix it because I can read the source. Invaluable.
Do you try and give it back to the developers, what if they reject it?
You are then in a situation where you are maintaining your own version of library X for your own project.
What happens if a new version comes out with significant changes?
Do you try and merge your version back together with it?
Github is helping to change this search problem, but there is much room for improvement. The less time it takes to find exactly what they need, the more likely they will find a project for possible contribution. (Obviously, this ignores the somewhat larger problem -- knowing what you need.)
I'm unaware of any financial arrangement that may occur when sponsoring a project, but it is literally incomprehensible to me why something could not be run like Google SOC so at least the community could benefit from our work. Students aren't being exposed to FOSS projects, so they're less likely to contribute after graduation.
not to say that open source C# doesn't exist, but it's just not as big a part of the culture.