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

That’s the message from Jacob Kaplan-Moss, one of the creators of Django, a very successful open source, Python-based web framework. At least some Django’s success can be attributed to its thorough documentation which is not just reference materials, but also includes tutorials, topical guides and even snippets of design philosophy.

Of course Django is not alone in having great documentation; Ruby on Rails is another highly successful open source project featuring great docs, tutorials and reference materials. Beginning to see a pattern? Great docs == happy, enthusiastic users == open source success.

Too often open source projects seem to turn up their nose at documentation, arguing that the code is well-commented or that developers should be able to figure it out for themselves — with the implicit suggestion that those who can’t don’t matter. That’s fine for some projects, but if you want your code to be more than a random page on Github, you’re going to need good documentation.

In an effort to help other projects improve their documentation, Kaplan-Moss has embarked on a series of articles outlining what he and the rest of Django’s developers have learned from the countless hours spent creating and refining Django’s docs.

While it’s worth reading through the entire series (and there’s more on the way), the basic message is quite simple: good documentation is more than just technical reference material.

What makes Django’s documentation stand out (and Ruby on Rails as well) is that it covers the details as well as the high-level overview of how the details fit together. Kaplan-Moss breaks down the types of documentation into three basic categories:

• Tutorials — Tutorials are a great way to introduce users to your software and demonstrate high-level concepts in real world examples. Too many tutorials teach you little more than how to create a “hello world” script. Good tutorials should help your users actually build something, which is much more exciting for a new user than printing out a line or two of text. As Kaplan-Moss says “that rush of success as you work through a good tutorial will likely color your future opinions about the project.” Tutorials are the best way to make a great first impression on your potential converts.
• Topical Guides — This is the real meat of good documentation and will be what users return to over and over again as they learn how to use your software. Kaplan-Moss’ advice is to aim for comprehensiveness: “the reader ought to come away from a close read feeling very comfortable with the topic in question… they should feel that they know the vast majority of the possible options, and more importantly they should understand how all the concepts fit together.”
• Reference — Sadly reference materials are in fact what passes for documentation in much of the open source world. That’s not to demean reference guides; complete lists of class names and methods are absolutely necessary, but don’t stop there. As Kaplan-Moss writes, “think of guides and reference as partners: guides give you the ‘why,’ and reference gives you the ‘how.’”

If you’d like to see an example of well-done documentation that covers all these ideas, look no further than the Django Project website, which hosts all of Django’s documentation. The Ruby on Rails community has also produced excellent documentation.

Kaplan-Moss has two more parts to his documentation series, one in which he delves into topics like writing well, developing a clear, grammatically correct style and another that focuses on editing.

Kaplan-Moss’ post on technical style also covers things like markup and structural layout of documentation, since even the best documentation is useless if you can’t find what you need. For example one of the best parts of Django’s documentation is that every topic and reference page has a liberal dose of inline links that make it easy to jump from one section to another. While we wouldn’t suggest using wiki software, the everything-is-a-link model of wikis makes a good starting point for marking up your online documentation.

One of the biggest hurdles for many open source projects is finding good writers to create documentation. While Kaplan-Moss has some suggestions for making yourself a better writer, many developers don’t have the time to improve their writing skills. To that end we suggest paying close attention to your community.

Watch for blog posts from your users that offer tutorials or provide an in-depth at some aspect of your software. Contact the authors and see if you can incorporate their posts into the documentation. Give your users a chance to contribute not just code, but their understanding of the code — ask them to write more and make them a part of the project when appropriate.

Finally, perhaps the most important message of Kaplan-Moss’ post is that ultimately… some documentation always trumps no documentation.” Maybe your documentation isn’t on par with Django or Ruby on Rails, but don’t let that stop you from producing at least something. And be sure to check back with Kaplan-Moss’ site for more articles on creating good docs for your project.

See Also:

• Django Project Looks Toward the Future With Django 1.2
• Making Open Source Software More “Humane”
• Flush With Choices, Developers Still Dig Django the Most

Ma.gnolia, a social bookmarking service similar to Delicious, recently announced it will release its code as an open source project. Under the new plan, dubbed Ma.gnolia 2.0 or just M2, interested developers will be able to download the source code and incorporate it into their own sites.

The move is similar to what Reddit announced earlier this year with its “build your own Reddit” customization features and open source code base.

However, the Ma.gnolia announcement isn’t just about open-sourcing the code. According to a post on the company’s blog, Ma.gnolia also plans to rewrite much of its own site architecture.

M2 is a ground-up rewrite of Ma.gnolia, re-creating features we love today, taking a second run at what didn’t worked as well as planned, on a distributed, service-based architecture designed to handle the large volumes of data we’ve seen.

While Ma.gnolia is nowhere near as popular as Delicious.com, the site is notable for embracing open web technologies like OAuth, OpenID, APML and more. Ma.gnolia also offers some very nice features — like screenshots of bookmarked sites and cached copies of pages — that Delicious doesn’t.

Among the features planned for M2 are a new “stream” view, which will show you the latest bookmarks from your friends, support for both OAuth and OpenID, as well as some visual changes, like the ability customize the sidebar or theme the site.

Particularly noteworthy is the continued OAuth and OpenID support which means that, using the M2 source code, you should be able to build and host your own bookmarking site, but still use the OpenID login tools.

The code isn’t actually available just yet, but Ma.gnolia plans to release it to developers in September, and offer a public beta version of the new site by December.

See Also:

• The Social Bookmarking Showdown: Ma.gnolia
• Reddit Embraces Transparency, Gives Away Source Code
• A Slap In the Facebook Follow-Up

Another major component of the iPhone announcement yesterday, in addition to the App Store I griped about previously, is MobileMe, the service previously known as .Mac.

For $99 per year, Apple will store all your data on their servers — email, calendar — and

auto-synchronize it to your desktop machine as well as your iPhone. It’ll all be accessible at me.com too, when that site launches, on what will doubtless be a flashy Ajax-heavy page.

Apple says “Me.com is such a great web experience, it seems as if you’re using desktop software,” and also “To use the new web applications, make sure you have one of these browsers: Safari 3, Internet Explorer 7, or Firefox 2 or later” — i.e., not IE 6.

Shortly after Apple’s announcement of MobileMe, I got a press release from Funambol, the open-source-happy mobile company, promising that their free sync software will do the same exact thing for free.

Good news for open source advocates: a recent study shows that not only is open source software reliable, the quality and security of open source software is getting better all the time.

The new study comes from Coverity, a long-time code analyzing company which has been running a statical analysis program known as Scan for the past two years. Scan looks at the source code of open source software projects to detect bugs and security flaws.

The Scan project is funded by the Department of Homeland Security, which wants to uncover (and fix) the most critical types of bugs found in open source software.

Coverity’s report, released May 20, shows that open source software is adept at rapidly patching bugs and even better, the overall number of bugs found has declined significantly in the last two years.

That means that not only are open-source developers creating high-quality new code, they’re also improving the existing code.

The report is based on 2 years of analysis of more than 55 million lines of code on a recurring basis, scanning over 250 popular open source projects like Linux, Apache, PHP, Perl, Python and other venerable names in the open source world. In that time some 8,500 individual defects have been corrected.

Although Coverity’s analysis isn’t going to detect every bug lurking in the dark corners of your favorite open source project, the survey does provide strong statistical evidence for the argument that code written by the community is every bit as secure and reliable as what you’ll find from proprietary vendors.

If you’d like more details on Coverity’s report, there’s a PDF available here.

[via OStatic]

See Also:

• Money, Not Spare Cycles, Drives Open Source
• Open Source Bites Back
• Linus Torvalds: Linux Put Open-Source in the Spotlight
• Patch Open Source Software

The Songbird media player, which aims to become the Firefox of jukebox software, continues to progress with recent builds focusing on performance enhancements. In case you’re unaware, Songbird is a web-enabled media player that makes it dead easy to browse, download and manage all of the media files out there on the web. Think of it as a mix of Firefox and iTunes. 

Songbird is one of our favorite music apps, but sadly its performance is subpar when faced with a sizable music library. Thankfully, Pioneers of the Inevitable, the company behind Songbird, recently released a nightly build demonstrating some impressive performance gains with large libraries.

Keep in mind that the release I used is what the Songbird team refers to as a “blessed” nightly; you don’t need to compile it from source, but it’s definitely alpha quality software.

That said, I’m happy to report that for the first time Songbird was actually able to scan and index all 140 GB worth of my music without issue. Once your library is imported, browsing through it, filtering by artist or album and even just scrolling no longer causes Songbird to hang, freeze or choke completely.

In short, version .6 of Songbird, due to arrive in June 2008, will be the first useable release.

The performance gains will be most noticeable in the Linux and Windows versions of Songbird where developers have turned on some of the same memory optimization tools found in Firefox 3. The Songbird blog claims that the performance improvement is “about 15-20 percent, depending on task.”

Now granted Songbird still has a way to go before it will replace iTunes or other jukebox software. While it finally seems to able to handle decent size libraries, scanning them will still bring your PC to a standstill. In my case it made my Mac essentially unusable for half an hour; iTunes and Amarok are both able to import the same library without crippling my PC. On the bright side, at least the scanning process only happens once.

I didn’t try importing my iTunes playlists since the plug-in that handles those features doesn’t work with the nightlies.

I continue to use the more stable, Songbird .5 release on a regular basis, but I don’t use it to manage my music library. Instead I set up a separate library for Songbird and use it for browsing and downloading tracks from my favorite MP3 blogs, which is where Songbird really sings.

If you’d like to test the latest “blessed” nightly, you can download a copy from the Songbird Nest. If you’re not up for running a nightly build, check out the video below which shows the latest release in action.

See Also:

• Songbird Inches Toward Becoming The Firefox Of The Jukebox
• Why Songbird Will Change Your Life
• Songbird Plays the Musical Web
• What to Do With 90,000 Songs?

If you’ve been itching to try out the new developer previews of GIMP 2.5, which we looked at back in April, but you aren’t comfortable compiling from source, we have a solution for you.

Wayne Richardson over at Fsckin w/ Linux put together a shell script that does the heavy lifting and even ensures that your compiled version won’t overwrite your existing version of GIMP.

To use the script just cut and paste the text into a new document, save it with a .sh extension and then fire up the terminal. Navigate to the folder where you save the script and enter chmod 755 savedscript.sh. To run the script just type ./savedscript.sh.

Be forwarned that it takes a while to compile GIMP 2.5 — about an hour on my old Toshiba, though with better hardware that time will be significantly less.

See Also:

• Developer Preview Shows Off the GIMP’s New Look
• Making Open Source Software More "Humane"
• Help Redesign The GIMP Photo Editor

Its plugin-based architecture makes it flexible for all sorts of uses; and it makes the analytic data easily available in a variety of formats: XML, JSON, serialized PHP. The data can also be gotten at in the form of embeddable widgets and iframes.

Piwik is still very much a work in progress, but a cool one. Try it out on your site, or check out the live demo.

See Also:

• Revamped Google Analytics Improves Traffic Tracking

A new group of analysts is trying to assess how much, and what, open source software is installed. To participate in the census, go to OSSCensus.org and download their free software package, called OSS Discovery. Sounds like a submarine.

It’s written, for whatever reason, in JRuby, a Java implementation of Ruby (the standard, official Ruby implementation is in C), and is itself open source, although the Census Edition is different in some way from the regular edition. It runs on most popular platforms.

I didn’t audit the code myself, and the site doesn’t provide MD5 checksums or any of the other assurances that are typical when you’re trying to persuade people to download and run something. At least it doesn’t insist you run it as root.

Once you’ve unzipped the 50MB package, take a leap of faith and run it on your computer. Discovery scans the filesystem, comparing what it finds against its included library of fingerprints, to try to figure out what (if any) open source software you have installed. I’m not sure how accurate the fingerprint method is, or how thoroughly patched and customized a piece of software can be before it fails to be recognized as itself.

Discovery is not as easy to use as Debian and Ubuntu’s popularity-contest, which automatically (optionally) tracks and reports installed packages without scanning, but this approach makes more sense across a very heterogeneous set of installations.

Here is the user guide for the software, and here are the scantyish reported results so far. 231 machines have been scanned as of this blogging. Mine are not among them: I let the software run on my server for about two hours before I got tired of its RAM greed and killed it. I anticipate that compliance may be a problem for the Census.

See Also:

• Making Open Source Software More "Humane"
• Git Excitement Continues to Grow

Sun recently experienced a hail of criticism when the company hinted that some add-ons for the popular open source database, MySQL, might be available only for paid customers.

Today Marten Mickos, former CEO at MySQL AB and now senior vice president of Sun’s database group, backed off the statement, saying that Sun has not made an official decision.

Sun, which acquired MySQL earlier this year for over $1 billion dollars, raised the ire of the MySQL community when it suggested that some high-end features due to arrive in MySQL 6 would be available only to paying customers.

A shrill chorus of critics on Slashdot and throughout the online world loudly condemned the potential move and accused Sun and MySQL of betraying the community that has helped make it successful. MySQL claims users in the tens of millions.

Mickos responded to the Slashdot post saying:

In 6.0 there will be native backup functionality in the server available for anyone and all (Community, Enterprise) under GPL.

Additionally we will develop high-end add-ons (such as encryption, native storage engine-specific drivers) that we will deliver to customers in the MySQL Enterprise product only. We have not yet decided under what license we will release those add-ons (GPL, some other FOSS license, and/or commercial).

However, Sun has made it clear that no final decision has been made and despite the inflammatory Slashdot headlines, MySQL isn’t going closed source.

In fact, even the high end tools aren’t necessarily going to be proprietary. Such a move might be bad news for paying customers as well, since it would mean the tools they pay for wouldn’t enjoy the widespread community testing that helps ensure they are usable and secure.

Even if Sun ultimately does end up making some MySQL tools proprietary, it’s very unlikely to affect the average user. The core database components would remain free and open source, only the extra tools would be affected.

See Also:

• Sun Shines the $1 Billion Light on MySQL Acquisition
• Google Releases MySQL Improvements
• Open-Source Patent-Holders Ready to Fight Fire With Fire