
Healthy Open Source Projects Need People - nslater
https://blog.engineyard.com/2014/open-source-software-contribution
======
mattgreenrocks
Another rant about the dangers of software rotting away if it ( _gasp_ )
hasn't been updated within six months. It appears people are _really_ bad at
assessing maturity of software, so they choose cheap metrics (like # of
commits / last commit), rather than examining the actual quality of the code
and design.

Eventually some smaller open source projects achieve feature-completeness and
no longer need any more features. It is healthy for them to declare themselves
done. This is distinctly different from maintainer apathy, though the symptoms
may be similar.

~~~
benatkin
This post didn't resonate with you, and so you just trash the author's work
without offering any real criticism? For shame.

~~~
saurik
I see a very concrete and specific criticism that both goes to the core of the
article it critiques and is backed up by argument. It is harshly worded, but
on the other side these kinds of "cheap metrics" lead to situations with high
emotions, so I have a difficult time blaming people for reacting strongly to
them.

~~~
benatkin
It's only relevant to the title. The article isn't saying that all
unmaintained projects suck. The article gives specific reasons why
unmaintained projects can't be used anymore, like depending on old versions of
programming languages. I suspect that the commenter didn't even read the
article, and I wonder if you comprehended it.

~~~
saurik
The article provides such reasons, but those reasons do not apply to every
project. I have been very happily been using software, such as ncurses, that
hardly ever sees a new version released, for many many years.

> In fact, this is such a big concern for me, that when I am evaluating new
> software, I judge it on two criteria. Firstly, how actively maintained is
> it? And secondly, how well does it do what I need?

This statement is the core of this article, and it demonstrates a fundamental
naiveté regarding the value of software. To try to put this problem
succinctly: if you come across software that has an army of people constantly
fixing it because for some ungodly reason it keeps breaking _you should run
for your life_ , not somehow be content that there is currently an army of
people bailing water from a sinking ship. He can thereby provide tons of
reasons as to why software that isn't maintained might break, but if he fails
to address the assumption that those reasons apply to software or at least
demonstrates an understanding that that is the first thing you should be
checking for, it doesn't really matter.

> I suspect that the commenter didn't even read the article, and I wonder if
> you comprehended it.

(I am pretty certain you are the one being needlessly insulting here, not
mattgreenrocks. He provided reasons to back up his points, and now in two
posts you've simply asserted that you are correct :/.)

~~~
nslater
The most important thing I wanted to communicate was that active contributors
are very important for a healthy project. And that if you add people to a
project, the project stands a chance of outliving your individual
contributions to it.

If a project required constant fixing because, say, the code was very bad,
then yes, I agree that would be a bad sign. But I was primarily thinking of
dependency maintenance.

I took a look at ncurses to see if I could learn anything about their success.

I count 18 contributors in the README file, which is exactly the sort of thing
I was thinking about really. Seems like the package has been passed from one
maintainer to the next as people's situation changes. This sort of thing is
important! If ncurses had met with the same fate as most GitHub repositories,
nobody would use it any more. It would be forgotten about.

I took a look through the configure.in file too, and it looks like ncurses has
very few dependencies beyond requiring a sane build environment. And I see
that ncurses releases once every few years, and has been doing since the 90s.
Oh, and the mailing list seems alive and well.

All in all, ncurses seems to be exactly the sort of healthy project I was
thinking of. Regular contributions, shared maintenance, very few dependencies,
and a predictable release cadence.

------
mkaziz
Does anyone know of healthy open source projects that need people? I'm a fresh
college grad and looking to sharpen my skills in my spare time - I like
javascript and java, and wouldn't mind the opportunity to get better at
python/ruby etc.

~~~
jamessocol
Check out OpenHatch [http://openhatch.org/](http://openhatch.org/). Connecting
people with time to projects with need is a big part of what they do.

------
dreen
This is very true and also the reason that you can't just dump a bag of cash
onto an OSS project and expect it to fare batter: Open Source projects run on
time, not money. The only way to give it more time is to have more devs that
are willing to commit their free time to it.

This is not to say you shouldn't give money to OSS projects. You should
definitely support your favourite programs even if its just $5 a year for a
single one you used that year.

~~~
coldtea
> _The only way to give it more time is to have more devs that are willing to
> commit their free time to it._

Or, you know, to pay devs to work on it on their work time.

That's how a great deal of progress for Linux/OSS came in mid-nineties to
mid-00s, when companies from IBM and SUN to Red Hat and Novell, paid lots of
programmers to work on critical parts (from the kernel and Apache, to Open
Office and Gnome). When that dried off, pace slowed down for a lot of
projects.

~~~
dreen
For majority OSS projects out there, that is not sustainable. As you said so
yourself, when the money runs out the project is in trouble, because when
those people inevitably get real jobs to cover their livelihood they become
less active or might even leave, feeling disincentivised (sp?). And with them
the knowledge about all the little obscure stuff goes away. Plus, if you had a
successful project and a nice job you liked, would you quit it because some
people on the internet promised to pay your salary? You just have no guarantee
they will do that.

~~~
nslater
Indeed. Commercial contributions are very valuable, but it's important to take
steps to reduce the inherent risk. If AcmeCorp stops paying its employees to
contribute to your project, do you still have a project left? If that thought
scares you, it's a good indication that you need to increase contributor
diversity. Perhaps that means more volunteer contributors, or perhaps it means
additional corporate contributions. But do not put all your eggs in one
basket!

------
al2o3cr
"They purposefully design technology to break after a few years, so that you
have to buy more of it."

[citation needed]

Seriously - I'm not denying that an awful lot of things break pretty quickly,
but it seems far more likely that this is cost-cutting leading to questionable
reliability, not outright "we're going to put a 1-day-after-warranty self-
destruct in this toaster!".

Besides, advertising to convince people that their not-broken thing needs to
be replaced with NEW-SHINY-THING seems much more effective - and less likely
to piss people off.

~~~
nslater
cf.
[http://en.wikipedia.org/wiki/Planned_obsolescence](http://en.wikipedia.org/wiki/Planned_obsolescence)

------
thrush
Have you heard of Facebook Open Academy [1]? It's an initiative to get
students more involved in Open Source.

[1] [https://www.facebook.com/notes/facebook-
engineering/facebook...](https://www.facebook.com/notes/facebook-
engineering/facebook-open-academy-bringing-open-source-to-cs-
curricula/10151806121378920)

