It’s often said that you can’t kill an open source project.

The logic behind that maxim is that, as long as the source code is out there and freely available, someone will always show up to work on it, add to it, improve it. Indeed, that’s often the motivation behind releasing a project under an open source license.

One example is tr.im, the URL shortening service that shut down temporarily, but whose code is now open source. Another is OpenTape, a clone of the popular (and long gone) Muxtape music streaming app. Both released into the wild after the original developers became overwhelmed in the hopes that someone, anyone, would keep those projects alive. Whether or not the community actually forms around the release is irrelevant. The point is that it could.

But what do you do when an ostensibly open source project lacks support from its creators, and it becomes nearly impossible for the community to contribute? That’s the question programmer Jeff Atwood raised in a blog post Tuesday regarding John Gruber’s Markdown software.

Markdown is a text-to-HTML conversion tool which allows you to write web code using an easy-to-understand plain text format. Markdown text is then converted to structurally valid XHTML (or HTML). Markdown is used all over the web — it’s even understood by the content fields and comment forms within most popular blogging platforms, including WordPress and Movable Type. It’s been ported to Python, Ruby, PHP and other popular languages.

However, the original Perl script has remained largely unchanged since its release in 2004. In his post, Atwood takes Gruber to task for what Atwood calls “bad parenting,” an indictment of Markdown’s lack of bug fixes, updates and improvements.

Markdown was released under a BSD-style open source license, meaning the community can do pretty much whatever it likes with the code, so long as it respects the copyright notices and naming rules. Indeed, many ports of Markdown enjoy rather widespread support with numerous contributors and an aggregate community of active developers that the original Markdown lacks.

So while the various implementations of Markdown have regular fixes and updates, Gruber’s original code lacks such activity. What’s the difference? Atwood lays some of the blame at Gruber’s feet, citing what Atwood calls “passive-aggressive interaction with the community,” and quotes one of Gruber’s famously bristly e-mails (Gruber also writes the famously bristly blog, Daring Fireball) that shows the author discouraging changes. Single programmers rarely have that sort of influence. Which isn’t to say we disagree with Atwood’s assessment, just that Gruber is an extreme example and that it shouldn’t matter either way.

The bigger reason Markdown’s original Perl source doesn’t see bug fixes and maintenance releases seems to lie more its hosting situation than any other single problem Atwood raises. Without a way to easily contribute to your project, your potential users can’t improve your code.

The Perl source of Markdown is hosted as static download on Gruber’s website. Download the zip file and you’ve got a copy of Markdown you can use, modify and even redistribute according to the terms of the license.

But you don’t have a copy that’s easy to patch, and there’s no simple way to contribute back to the project, short of sending code directly to Gruber or to the support mailing list.

If the Markdown source code lived somewhere like GitHub, BitBucket, Google Code or any of the other free, open source code repository hosts, it would be infinitely easier for the community to contribute. To be fair, none of those sites existed when Markdown was released, but moving the code wouldn’t be hard — it’s a single archive with a license and readme text file.

A good project hosting service allows the community to contribute in ways that it just can’t when the code is static download.

Markdown isn’t alone in this respect. Django programmers were very excited to get their hands on the EveryBlock source code when it was finally released. However, since the EveryBlock code is, like Markdown, a static download, there isn’t and easy way for the community to contribute.

I have been using the EveryBlock code in a personal project for some time, and I’ve found at least a dozen bugs and several oversights and contradictions in the documentation. None of these stumbling blocks have stopped me from using the code, but it would be nice if I could contribute patches so others don’t also have to bang their heads against a wall for days on end trying to make the code work.

Yet a static hosting environment prevents that. There’s no easy way for me or anyone else to contribute to the code, update the documentation, add helpful links to a wiki, ask a question and get it answered. As a result, the whole community around the project suffers.

While it’s true I could put the codebase into a version control system and host my own copy, but not only does that feel wrong, it shouldn’t be necessary. The “you can always fork it” motto of open source has proved one of its least helpful tenets, leading to a proliferation of nearly identical code forks that are difficult to keep track of and work with.

We understand that the people who release open source code might not have time to work on it, or might simply lose interest in it over time, but that’s precisely why version control systems exist — to take the burden off the developer and let the contributions of the community pick up the slack in an open, organized manner.

Does a project still need an maintainer and someone to check in code, run tests, merge branches and so on? Sure, but that need not be a single person. Sizable open source projects — take Firefox for example — have dozens of committers and (in theory) no one person winds up feeling overwhelmed.

While in this particular case, it could be argued that Markdown doesn’t need further development. We use it everyday without issue. But the larger issue remains for other projects. Without active development, particularly bug fixes and maintenance releases, your open source project will rarely be successful.

Get your code into a decent version control system and make it easy for other users to do what you don’t have to — make your code better.

Photo by gerhard3/CC BY-NC-SA 2.0

See Also:

• Why Great Documentation Matters in Open Source
• Making Open Source Software More “Humane”
• Money, Not Spare Cycles, Drives Open Source

Go to Source