

Why don't more developers contribute to open source? - tkellogg
http://timkellogg.me/blog/2012/05/03/open-source-meetup-group/

======
bunderbunder
_If each one of us contributed just a little bit of time to the open source
software that we love, we could prevent hundreds of valuable projects from
going stale or dying._

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?

------
PaulHoule
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.

~~~
lucian1900
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).

------
brown
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

~~~
Derbasti
I guess that is still valuable. Maybe someone else will pick it up and write
the tests for it. Contribution is contribution is great!

~~~
tkellogg
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...

------
jgmmo
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!!

------
Derbasti
> 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.

~~~
jiggy2011
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?

------
pathdependent
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.)

------
pdubs
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.

------
teeray
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.

------
cubiq
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/...

------
AdrianRossouw
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.

