what is open source --everyone has access to source --Many users read source, understand, report bugs --typically free to get, but not necessarily --Typical pay to use (support) --many many products. --very successful, viewed as a major new force in the software industry. --adopted by companies internally. History of open source projects. --1984 Stallman organizes GNU --1984 MIT X Consortium for distributed windows. --1989 GNU Public License Legalese Crafted --1991 Linux first released --1995 Apache first released --1998 Netscape goes open source. Why is it interesting? very high quality, productivity, etc. low cost How is it doing? Just Great. (google for "chart market share mozilla, apache" etc) Why does it work? people are selfish--why do they work on open source projects? some reasons: --software (by revenues) is primarily a service industry, not a manufacturing industry. Sale value vs. Use Value of products. (where are the jobs? mostly in services, not mass-market product development. consider what happens products without support, e.g, even music "software" vs. real software) so making software free is not that surprising business wise. --why do people contribute to software? Consider individual's decision when confronted with a bug that really bothers them. If you can fix, you will; you have the source! once you fix it, why sit on it ? "The tragedy of the commons" is not applicable here: "Free riders" don't cost anything, so "bad citizen" is meaningless, to a point. --often it makes sense to open-source a product you develop for yourself. (e.g, Cisco printers, ) "sunk" cost doesn't count---you had to develop the tool anyway. The only question is, does the benefit of open-sourcing outweigh the costs of having your competitors getting to use it. How is organized: Typically a smallish core group of developers (a small proportion of the total population of developers). Some Principles of Open Source Development. (Cathedral and Bazaar) 1. Every good work of software starts by scratching a developer's personal itch. 2. Good programmers know what to write. Great ones know what to rewrite (and reuse).. 3. When you lose interest in a program, your last duty to it is to hand it off to a competent successor. 4. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. 5. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''. WHy? Perhaps delphi effect (average of large number of people's opinions is usually better than any single opinion). But perhaps the next reason (#9). 6. Developers are better bug reporters that mere (mortal) users. (belief is that finding bugs is harder than fixing them). Source code level bugs, when reported, might actually reflect etiology of multiple user-level bugs. 7. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. Talk to them a lot, admire their work publicly, chat them up in emails 8. Having good ideas is silver. recognizing good ideas from users is pure gold. If you unabashedly flatter and praise your users, they will recognize your in turn and call you a genius. IN some sense, it's not even necessary to have a great initial idea to start off an open-source project-- it's better to be clear, straightforward, uncomplicated etc. Of course, you must have the ability recognize new good ideas. 9. The ``utility function'' Linux hackers are maximizing is not classically economic, but is the intangible of their own ego satisfaction and reputation among other hackers. ("egoboo") "Many people (especially those who politically distrust free markets) would expect a culture of self-directed egoists to be fragmented, territorial, wasteful, secretive, and hostile. But this expectation is clearly falsified by (to give just one example) the stunning variety, quality, and depth of Linux documentation. It is a hallowed given that programmers hate documenting; how is it, then, that Linux hackers generate so much documentation? Evidently Linux's free market in egoboo (ego boost) works better to produce virtuous, other-directed behavior than the massively-funded documentation shops of commercial software producers. " 10. What about Brooke's Law ("adding more software developers to a late project makes it even later"). Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one. 11. OPen source projects have no management. But management serves several important functions in traditional projects. -- To define goals and keep everybody pointed in the same direction --Perhaps the only role for traditional managers. -- To monitor and make sure crucial details don't get skipped --See the bit about eyeballs. -- To motivate people to do boring but necessary drudge-work --Not a problem--boring projects just die. - To organize the deployment of people for best productivity --The self-organize. Typically top 5% most competent become inner circle - To marshal resources needed to sustain the project -- Money: who cares? People volunteer. -- People: no need to hire. self-select the best---in fact the incompetents are never on staff, so less problems -- Office Space: no problem!