A word of explanation is in order (June 30) -- when I wrote this, I was all afire with participating in my first open-source project, and recovering from my entire previous twelve years of corporate software development. I made good money with that corporate development, but disliked the process. Now, eight years after I wrote this article, I don't make money with software development at all; I develop software for fun and love it far more. Your mileage will probably vary.
And for God's sake, somebody who is Stumbling onto this page tell me what the attraction is. It's driving me absolutely insane. What are you people doing reading a tepid article on open-source software written eight years ago?
(July 14 - more than a thousand hits today. Still nobody is saying why. I suspect the Internet is laughing at me. Go ahead, stumblers. Have your little joke. I can take it.)
That ranted, let's commence the article as written:
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. [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: 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. [Currently, 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. [Looks like I flubbed this one to a certain extent, because "making money giving things away" is a bit of a straw man, but I still say a large corporate structure and honesty are fundamentally incompatible. Also, my business failed because I was thinking 1. Develop, 2. ???, 3. Profit. The lesson to be taken away is that open source is a software development strategy, 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. 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. [Except the poor slob's politics. And it appears that link is a good ol' 404 now anyway. Oh, well. Life goes on.] 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. [But of course, I didn't.]
Here are the initial links I came up with in April of 2000.
- 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.
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.