Topic: Open Source

Well, the short answer is: an open source product is provided in such a way that users of the software can find and fix their own bugs. It is organized in such a way that fixes can easily be incorporated into the main code, and that people can easily join or leave the group without affecting the flow of information much. In other words, open source has a very robust development model. It can evolve very, very quickly, and it can get as nearly bugfree as software can get, simply because the people actually using the software are empowered to detect and fix errors.

Sounds great, doesn't it? Well, it is. There's just one sticky wicket: it stems from a culture radically different from American capitalism. The open software movement originated in the hacker culture of the 70's, and that culture is a gift culture. In fact, the original "free software" movement was radically anti-commercial in its philosophy, and it's still not unusual to see licenses on free software that precludes commercial use (or demands special licensing for commercial use.)

However, things are changing -- Linux and Mozilla have proven the legitimacy of the open-source concept for American business. Now everybody's trying to figure out how to do business on an open-source basis. Uh, wait. How do you give things away and still make money? Well, nobody's quite sure about that one. There are a number of models which are being tried out, but if you want my opinion, it's this: open-source businesses will never be very large. A large corporate structure simply will collapse under its own weight if it is forced to the high degree of honesty required by an open-source model.

I'm starting to see some new ideas out there in the "capitalist open-source" market. The obvious idea is a matchmaking service, whereby corporate (or other moneyed) sponsors can post requests and hire developers to implement them. I'm participating in two of these: SourceXchange and CoSource.com. SourceXchange was the enabler for my wftk project and is geared towards projects roughly in the $10,000 to $15,000 range. CoSource has a much simpler project model and is really geared towards projects in the $500 to $1000 range, but I'm currently working on a proposal there for a $7,500 project. Each site is definitely worth watching.

So how do you really start up an open-source project? Eric Raymond, one of the prime movers of the open-source culture, has a few very salient points in his essay the Cathedral and the Bazaar. He also has a few other things in there, and it's definitely worth a read, so go read it. Heck, while you're at it, go up a directory and read everything else in there. But here is my short interpretation:

• Start with a problem that is interesting to you and hopefully to others.
• Write or find a halfway decent solution to this project.
• Find the people that need this solution.
• Set up your infrastructure.
• Respond to any and all questions and suggestions.

So what sorts of things do you have to provide in your open-source project's infrastructure, and why?

• Access to the code and to whatever precompiled versions you can provide.
  The code is of course required for this to be open source. Many groups stop right there, presuming that people interested in open source will be able to compile their own software anyway. In my own opinion, however, the community should be easy to join, and that means not having to fight with the compiler to start. (The reason for source-only distribution, of course, is that most open source is Unixware, and portability between Unix versions is fraught with extreme peril. It's easier not to mess with executable distributions.)
• Your community needs to be able to communicate.
  This need is fulfilled by a number of different mechanisms: traditionally, mailing lists have been used for communication about open projects, but any such system will do. So you can set up a mailing list, a Usenet newsgroup, or a Web-based bulletin board, but you have to provide an easy means of communication or you have no community and no open source project. If you set up one, be prepared for complaints that you're not using the others. In fact, no matter what you do in open source, be prepared for complaints that you're leaving somebody out.
• Fixes and patches need to be easy to provide.
  The most popular solution to this problem is CVS. CVS is a version-control system that is easily used in a decentralized environment, and of course it's open-source. The other popular solution is "mail me any patches and I'll incorporate them." The danger of having a single lead, of course, is that should the lead lose interest it may be difficult to keep the community together.
• Documentation should be profuse and easy to find.
  This should be obvious. However, the problem with open source in general is that the people writing it are brilliant and focussed on solving the immediate problem (or developing the immediate cool feature.) So documentation, while always present, is sometimes nearly as opaque as the code itself, and very often it's much simpler just to read the code. (On the other hand, sometimes somebody was motivated to write some good documentation, and then it's brilliant.) Documentation is commonly included with the code in the form of man pages or HTML. And in almost all cases I know, documentation is also linked directly from the project's home page.
• Bug reporting should be easy
  This is another case where many projects aren't too well organized. Bugs are generally identified using the mailing list, and lead developers often maintain a to-do list in the form of a text file. The TODO file is sort of an informal standard, and contains known bugs and suggested enhancements for the product. Note: most bugs are fixed as soon as they're found, so the list of known bugs is very often quite short and contains bugs that are difficult to encounter. It really isn't as horrible as it sounds -- and not a tenth as horrible as the list of known bugs you can sometimes find with closed software.

That's what I have to say about open source right now. I'm embroiled in leading a real live open-source project even as we speak, but so far that is just in its early coding stages. There is a small discussion community in place and I get the occasional interested email, but as no-one is yet using the product, most of the grist for the open source mill is yet to come. I'll try to keep this page updated with my experiences.

• The Open Source Initiative
  This is the website of the people who trademarked the phrase "open source" in order to prevent it being coopted by... certain people who tend to coopt things. Contains the offical definition of open source, some of the history of the movement, and such things.
• The Cathedral and the Bazaar
  The essay by Eric Raymond about the two major competing philosophies, with some important point-by-point tips on starting and running an open source project.
• SourceXchange
• CoSource.com