Originally written April 8, 2000, by the date stamp on the file; commentary added June 23, 2008, then a very little more in 2020.

Against all sane expectations, open source is recently quite the buzzword. Why? What the heck is it, and how does it differ from traditional corporate software development?

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. [Note 2008-06-23: So far, I still agree with all this.]

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.) [Note 2008-06-23: remember, this was written in 2000. I haven't seen anti-commercial licensing since the GPL became widespread, but it was originally rather common. I stand by my cultural distinctions. There are, of course, some people making money off open-source software. Lots, actually. But open-source will not, and cannot, create corporate behemoths with billions of dollars, such as Microsoft. You can't be as honest as open source demands and still market for the money Microsoft demands. Can't be done.]

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. [In 2008, everybody's pretty sure that the answer is "services".] 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. [2008: Looks like I flubbed this one to a certain extent, because "making money giving things away" is a bit of a straw man. I still say a large corporate structure and honesty are fundamentally incompatible. Also, my business failed in 2004 because I was thinking 1. Develop, 2. ???, 3. Profit. The lesson to be taken away is that open source is a software development strategy, and is very much not a business plan.]

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. [Of course, they died.]

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.

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.

What you need to do is to create a community of technically capable people who are using the product. If you do this, and if the community is stable, then your product will evolve very quickly and become quite robust. This is the "bazaar" metaphor for open source. (The opposing concept, the cathedral, typifies the closed shop: instead of a messy, noisy, open structure going in ten directions at once, the cathedral is quiet, attended by cloistered monks, and attempts to look perfect at the cost of not changing very often.)

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. [Note 2020-11-28 as I move to yet another publishing system: Github is of course the most popular solution today.]

• 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.

[And this model's still good, if you ask me in 2008.]

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. [But of course, I didn't.]

Note 2008-06-23:

I originally wrote this during initial development of the wftk toolkit, which (yeah) turned out to be too damned complicated to finish as originally conceived. And then Life Happened, as I've documented volubly elsewhere. My kid got sick, my country went batshit insane, my business failed, and all sorts of stuff happened, and I frankly forgot I wrote this at all. Today, however, I see 23 links in from StumbleUpon. Isn't that weird? So, what the heck. I Wiki-ized the page and updated it, for what that's worth. I think that one review misses the point of this page, actually -- this is meant to give the recovering corporate programmer some idea of how fricking different open source really is. And if you think the gift economy is compatible with commercialization, well, all I can say is good luck to you on your journey through life.

Note 2020-11-29:

It's kind of sweet how 2008 me thought America was insane then.