Healthy Open Source Projects Need People
blog.engineyard.com
blog.engineyard.com
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.
The problem arrises when the things your program depends on go away. For example, if you have a project that is written for Ruby 1.8.7, after June of this year, that version will receive no more updates. If there's some particular feature of 1.8.7 that you depend on, or some bug found, or some security vulnerability discovered, users might eventually find themselves in a spot of bother.
The web of dependencies for most projects is bewilderingly complex. The stacks that we write for are moving targets, and unless your software is moving to keep up, eventually there's a good chance that they just wont run any more.
This sort of thinking is why the IETF publishes Internet Drafts as ASCII-only text files. They've limited the dependency chain to ASCII, because they are hoping that isn't going away any time soon.
Galileo: No, Andrea: Unhappy is the project that needs a coder.
I've found that those shallow metrics, especially "last commit", are quite telling for a project's health.
Sure, a small project can achieve "feature-completeness". Still, if it's not being touched at all for over 2 years, I wouldn't want to depend on it.
Especially if it also has several year old issues in the bug tracker.
The thing is, I have zero guarantees that the maintainer even cares about this project, that it will be updated when something breaks of changes (e.g it needs some fixes to compile on a new OS release) etc.
That the project is Open Source and "anybody" could do that theoritically is not much of a guarantee. There are tons of open source projects that languish with no one updating them.
Including some I unfortunately had to rely on, but don't have the time/knowledge/etc to jump in and contribute. Case in point, wkhtmltopdf.
> 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 :/.)
The article doesn't say it applies to everything, but if you read the title as a thesis statement and not simply a title, the title implies it. Article titles are short and don't capture everything.
> I am pretty certain you are the one being needlessly insulting here, not mattgreenrocks.
OK fine, you have more karma on HN than me, so you're right. Are you happy now?
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.
[0] supmua.org
I'll put in a plug for jQuery, see http://contribute.jquery.org for some guidance. There are plenty of things to do in every project besides hardcore coding as well, such as documentation or build systems.
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.
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.
[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.
[1] https://www.facebook.com/notes/facebook-engineering/facebook...