Why don't more developers contribute to open source?(timkellogg.me)
timkellogg.me
Why don't more developers contribute to open source?
http://timkellogg.me/blog/2012/05/03/open-source-meetup-group/
11 comments
Well, there are a few reasons.
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.
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.
I've found that almost always when I released something sub-standard that at least some people care about, someone fixed it.
This has sometimes included a crap/missing build system, although it is important (if people can't use it they're unlikely to care).
This has sometimes included a crap/missing build system, although it is important (if people can't use it they're unlikely to care).
Good developers know that writing code is only 1/10th of the work. Then you have to test it, write automated tests, support it, maintain it, etc, etc.
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 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 guess that is still valuable. Maybe someone else will pick it up and write the tests for it. Contribution is contribution is great!
I usually reject pull requests with no tests. For one, tests often do a better job describing what the pull request is for than the actual description. Also, it's easier if they think through all the corner cases. It's true, it makes a bigger barrier to entry. But on the other hand, it also gives more value to the contributions. But maybe I should rethink my stance...
I have to admit I was one of the intimidated folks. Recently I started using Github to host a few projects I have opened up and I am really excited. For both contributing to other projects, as well as getting help on my own stuff. Seems like I could have speeded along my development expertise had I started using Github back when I signed up for it in 2008!!
> The experienced also don’t mind digging into code
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.
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.
The problem is though, that once you have done your fix. What then?
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?
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?
I think there is also an issue of ignorance. Developers get caught up in the immediacy of their need, do a cursory search for something that fits, then roll their own if it is not immediately found. There are many open source projects that would be extended if developers found them at their time of need. The open source project has to lie somewhere between "this is perfect" and "this will save me so much time with only minor modification."
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.)
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.)
The majority who contribute say state "Because I enjoy it, it's a hobby" as their reason. Different people have different hobbies. Just because someone develops for a career doesn't mean that it should automatically be their hobby too.
Our CS depatartment, like many others, has a senior project class. Students have no input on what their project will be or who it will be for. They generally tend to be projects sponsored by a gov't organization that shelves the project once it's finished.
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.
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.
the experienced probably doesn't like your code and end up creating a new project that does the same thing and that will eventually die for lack of time/resources/will/...
because the author is working on a microsoft platform (C#).
not to say that open source C# doesn't exist, but it's just not as big a part of the culture.
not to say that open source C# doesn't exist, but it's just not as big a part of the culture.
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?