Aaron Cayard-Roberts
Paper on the Cathedral and the Bazaar
V1.0

V1.0
11-2-00

Eric Raymond makes many points in The Cathedral and The Bazaar but the major ones describe rules of thumb for successful open-source programming. The first one is that every good work of software starts by scratching a developer's personal itch. Which means you will try harder if it is something that you are interested in and want to do, which makes perfect sense to me. Another one is for the least-hassle route to rapid code improvement and effective debugging is to treat your users as co-developers. So if you respect your users as equals they are more likely to help you out because you're being a nice guy. Another rule of thumb that Eric gives is release early, release often, and listen to your customers. This allows your users to have access to the more of the bugs and potentially letting them fix them for you, if you bother to listen to them. The last big point that Eric makes is that given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. He also states this as "Given enough eyeballs, all bugs are shallow" which he dubs "Linus's law." All of these sound like sound advise as far as I'm concerned.

In Homesteading the Noosphere Eric describes the open-source community as a gift culture and how that ties in with the taboos of the open-source culture.

He first describes the actions of the open-source community in terms of a gift culture. What it comes down to is that because hackers don't have a shortage of survival necessities (disk space, network bandwidth, and computing power) and with software that is freely shared the only available measure of competitive success is reputation among peers. I would have to say that this is not always true. Some hackers, students in particular don't always have all the computing power and other things needed to 'survive', and furthermore some of them don't care what there peers think and are competing with themselves, although the later is a much rarer occurrence.

One of the taboos that Eric talks about is ownership of the code. He first describes several ways that ownership can be obtained. This is where the homesteading part of the title comes from (on the frontier where land exist that has never had an owner, can acquire ownership by homesteading it). So by working on unclaimed code and improving it you obtain the title of owner of it. Another title acquisition method takes place when there is a current owner who is no longer working on the code and they pass it off to someone that is interested in working on the code. And finally a title can be claimed if it has been abandoned. This is done when someone starts improving it and defends the title as if homesteading. I think that this does describe the important aspects of ownership, but it could be put in much simpler terms, and isn't some complex thing that needs lots of explanation.

The taboos that Eric relates to the idea of the open-source community being a gift culture have to do with ownership rights and reputations. Eric states that forking is avoided in the community because it's a reputation risk for both of the child projects and is splits the user base. I would say that in most cases forking would be avoided because the splitting of the user group can be lethal to one or both of the new code lines and not so much because of the reputation risks of the project maintainers. He also points out that distributing rogue patches is also looked down upon because the maintainers tend to be held responsible for any bugs in the patches even though they didn't have anything to do with them. I would agree, but it might also have to do with how other people would perceive a person who thinks that they are better then everyone else and don't need to submit their code to the maintainer and let them do the patch. The last taboo about ownership and Reputations is the thief of code by 'filing' someone's name off of it. I think that this is a very good parallel between the gift culture and the open-source culture.

The major topic that Eric Raymond discuses in The Magic Cauldron is the funding modules that exist for software. The open-source funding comes from the use value of software which he says makes up about 95% of the industry. This leaves only 5% of the software being funded by the sale value, so if the market became driven by open-source software it really wouldn't effect that many programmers. He then describes some successful use-value funding models.

The first one was the Apache group. In this model it was more cost effective for a group of webmasters to pool their efforts into improving one code base then to run a large number of parallel development efforts. This model was successful (Apache now has 61% of the market share) but I'm not to sure that it's a good example of a funding model. This shows that it is cheaper for a company to use open-source software instead of developing it themselves but he never explains how this funds the software developers.

The next example of a use-value model is the Cisco case. Here the programmers did get paid while they worked on it, and the company got a good deal because the code would still be worked on after the programmers left the company. This works because the company didn't have anything to lose by open-sourcing the code and gained indefinite updates from the community.

Eric then give 7 indirect sale-value models that work for open-source software. The fist one is the loss-leader/market positioner. Here proprietary software that is about to lose a market position can open-source to stay afloat. The open-source client software still enables the sales of server software or subscriptions/advertising for revenue. Another model that he calls widget frosting is when your selling hardware but to sell it you need software to go with it, so why not use open-sourced software. This seems like a very good way for hardware companies to make money, but I'm still not seeing a programmer getting paid here. Eric's 5th model called give away the recipe, open a restaurant, which sounds like the best bet to me. Here you give away open-source software but make users pay for things like service support. The 6th one, called accessorizing, you just sell accessories like t-shirts and professionally-edited docs for open-source software. The 7th,called free the future, sell the present, where you sell the binaries and code but put a time limit before it goes under GPL terms, is a good idea but I would bet most people would just wait for the license to expire and live with an older version instead of buying it. Eric's next model, called free the software, sell the brand, sound like it could work, but releasing just part of the code would be kind of tricky to do. His last one ,free the software, sell the content, sounds great to me, although I wouldn't want to pay AOL for a subscription to chat over aim, just so I could have the source code, since its free right now, but it could work for other software that provides more services that are worth paying for.