Healthy Open Source Projects Need People(blog.engineyard.com)
blog.engineyard.com
Healthy Open Source Projects Need People
https://blog.engineyard.com/2014/open-source-software-contribution
23 comments
This post didn't resonate with you, and so you just trash the author's work without offering any real criticism? For shame.
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.
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.
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 :/.)
> 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 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.
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.
> 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.
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?
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?
It is possible to reach feature-completeness. TeX is probably the most well known example of this. It was feature-frozen at 3.0, and the only changes made now are bugfixes.
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.
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.
Andrea: Unhappy the project that breeds no coders.
Galileo: No, Andrea: Unhappy is the project that needs a coder.
Galileo: No, Andrea: Unhappy is the project that needs a coder.
>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.
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.
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.
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.
Check out OpenHatch http://openhatch.org/. Connecting people with time to projects with need is a big part of what they do.
Every Open Source project needs people. Find one that is doing things you are interested in and take a look around for things to do. Be sure you like the vibe of the project as well, do the people seem like folks you'd want to hang out with in your free time? It's not supposed to be a boring or tedious job, you may already have one of those so it should be fun.
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.
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.
In the continuity of OP's post, I'd like to introduce sup [0], a MUA project written in ruby a long time ago by William Morgan to put gmail functionalities in your console. It has seen quite a success (even creating a fork-for-speed, notmuch [1]). Unfortunately William has left the boat, and sup is now maintained by other people. It's still hackish and has some bugs, but it does the work fairly well. Help is highly welcome !
[0] supmua.org
[1] http://notmuchmail.org/
[0] supmua.org
[1] http://notmuchmail.org/
Check out quill.org. We're an open source tool for learning English grammar. We've got an active community of developers at https://github.com/empirical-org/quill, and we currently have about 500 students using our site per day. There are a variety of front end and back end projects. Feel free to reach me at peter (at) quill (dot) org.
I'm sure there are plenty! You could start by picking a project on GitHub that seems interesting. Have a look at the open issues to see if there's anything you could fix. Most repository owners will be very grateful for pull requests, and are usually happy to provide feedback on your code.
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.
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.
>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.
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.
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.
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!
"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.
[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.
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...
[1] https://www.facebook.com/notes/facebook-engineering/facebook...
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.