book

Open Sources 2.0

by Chris DiBona, Mark Stone, Danese Cooper

October 2005

Intermediate to advanced

488 pages

17h 4m

English

O'Reilly Media, Inc.

Read now

Unlock full access

1.1. Founding of the Mozilla Organization: Obvious for Developers, a Bold Step for Management1.1.1. Updating the Codebase1.1.2. A Disciplined Methodology1.1.3. Building an Open Source Project1.2. Young Adulthood—the Mozilla Foundation1.2.1. Firefox and Thunderbird1.3. The Future
2.1. Proprietary Versus Open Source?2.1.1. The Example Culture2.1.1.1. Code reuse? Knowledge reuse!2.1.1.2. Speed of development2.1.1.3. A particularly difficult codebase2.2. Comfort2.2.1. But Why So Many of the Same Things?2.2.2. Libraries, System Calls, and Widgets2.3. Distributed Development2.3.1. Understanding Version Control2.3.1.1. CVS2.3.1.2. Subversion2.3.1.3. What About SourceSafe?2.3.1.4. The Special Case of BitKeeper2.4. Collaborative Development2.4.1. IRC/IM/Email2.4.2. VoIP2.4.3. SourceForge2.5. Software Distribution2.5.1. Dependencies2.5.2. Online Updating/Installation2.6. How Proprietary Software Development Has Changed Open Source2.6.1. Bugs/Security2.6.2. Testing and QA2.6.3. Project Scaling2.6.4. Control2.6.5. Intellectual Property2.7. Some Final Words2.7.1. Free Things Are Still Cheaper Than Expensive Things
3.1. The POSIX Standard3.2. First Implementation Past the Post3.3. Future Proofing3.4. Wither POSIX?3.5. The Win32 (Windows) Standard3.6. The Tar Pit: Backward Compatibility3.7. World Domination, Fast3.8. Wither Win32?3.9. Choosing a Standard
4.1. Many Eyes4.2. Open Versus Closed Source4.2.1. Who Is the Audience?4.2.2. Time to Fix4.2.3. Visibility of Bugs and Changes4.2.4. Review4.2.5. Who’s the Boss?4.3. Digression: Threat Models4.4. The Future4.5. Interesting Projects4.6. Conclusion
5.1. Business and Politics5.2. Open Source: Distribution Versus Development5.3. A Primer on Intellectual Property5.3.1. Ownership5.3.2. Licensing5.4. Dual Licensing5.4.1. Reciprocity5.4.2. Warranty5.4.3. Competitive Issues5.4.4. Ownership5.5. Practical Considerations5.5.1. Attractive Margins5.5.2. Capital5.5.3. Choosing Licenses5.5.4. Need and Pain5.5.5. Measuring the Market5.5.6. Piracy5.5.7. The Social Contract5.6. Trends and the Future5.7. Global Development5.8. Open Models5.9. The Future of Software

6.1. Commoditization and the IT Industry6.2. Decommoditization: The Failure of Open Systems6.3. Linux: A Response from the Trenches6.4. “So, How Do You Make Money from Free Software?”6.5. The First Business Models for Linux6.6. Linux Commercialization at a Crossroads6.7. Proprietary Linux?6.8. What’s at Stake?
7.1. Introduction7.2. A Brief History of Software7.3. A New Brand of Intellectual Property Protection7.4. Open Distribution, Not Source7.4.1. The Open Source Weapon7.4.2. Proliferating Open Source Beyond the Enterprise7.4.3. So, Why Not Freeware?7.4.3.1. Don’t view. Don’t modify. What do you do?7.4.3.2. Open source. Open choice. Open wallet.7.5. Open Source Business Models7.5.1. Both Source (a.k.a. Mixed Source) Model7.5.2. Professional Open Source (a.k.a. Services) Model7.5.3. Dual-License Model7.5.4. ASP Model7.5.5. Other Models7.5.5.1. Managed source model7.5.5.2. Code-level service model7.6. Conclusion
8.1. Open Standards8.2. Open Source Software8.3. The Real Business Model8.4. Open Source Complements8.5. Open Standards Complements8.6. Conclusion
9.1. Introduction9.2. Freemacs and Open Source9.3. Freemacs and Business9.4. Packet Drivers9.5. Packet Driver Income9.6. Qmail9.7. Open Source Economics9.8. Where Do We Go from Here?9.9. For Further Reading
10.1. From Movable Type to MovableType10.2. Copyright in Code10.3. Secondary Liability10.4. Anticircumvention10.5. The Threat to Research10.6. Technology Mandates10.7. What About That Media Server?
11.1. Brief Summary of an Already Long History11.2. The Development Community11.3. The Organization of the Community11.4. Libre Software in the Private Sector11.5. Public Administrations and Libre Software11.5.1. Actions by the European Commission11.5.2. National Initiatives11.5.3. Other Initiatives in the Public Sector11.6. Legal Issues11.6.1. EU Directives with Negative Impact11.6.2. Libre Software Licenses in Europe11.7. Libre Software in Education11.8. Research on Libre Software11.9. The Future Is Hard to Read....
12.1. Business12.1.1. Domestic Market12.1.2. Outsourcing and OSS12.2. Government12.3. Challenges in Local Adoption of OSS12.3.1. Support12.3.2. Piracy12.3.3. Localization12.3.4. Culture12.3.5. Software Patents12.4. OSS in Education12.5. Conclusion
13.1. What OSS Was and Is in China13.1.1. What OSS Means in China13.1.2. Status of OSS in China13.1.3. OSS Business Models in China13.2. SWOT Analysis of OSS in China13.2.1. Strengths13.2.2. Opportunities13.2.2.1. The market for embedded software outside the conventional desktop or server opportunities13.2.2.2. Delivering innovations and unique end-user values on top of available OSS—values not currently served by the presently available software.13.3. Where OSS Is Going for China and Beyond
14.1. Livre Versus Gratis14.2. Background for Freedom: The Market14.3. Developing the Software Livre Movement14.4. Not About Price, but About Choice14.5. Choice Requires More Than Free Software14.6. How Java Technology Can Help14.7. Java Provides the Other Side of the Choice14.8. Walking the Path14.9. What to Do?14.10. We Are Getting There14.11. References
16.1. Software as Commodity16.2. Network-Enabled Collaboration16.3. Customizability and Software-as-Service16.4. Building the Internet Operating System16.5. Conclusion
17.1. How Did It Happen and How Does It Work?17.2. Working as a Group17.3. Dealing with the Disrupters17.4. The Difference Between Doing Legal Research in Public and Writing Software in Public17.5. Why and When It Works
18.1. The Rise of Modern Biotechnology18.2. Intellectual Property and Growing Challenges18.3. Open Source Biology18.4. Synthetic Biology and Genomic Programming18.5. The Risk of Biological Hacking18.6. Future Trends in Open Source Biology
19.1. The PACT Project19.2. The World Trade Center Recovery Effort19.3. Facilitating Emergent Collaboration19.4. Acknowledgments19.5. References
20.1. Some Recent Press Reports20.2. Nupedia20.3. The Origins of Wikipedia20.4. Wikipedia’s First Few Months20.4.1. Why Wikipedia started working20.5. A Series of Controversies20.5.1. The governance challenge20.6. My Resignation and Final Few Months with the Project20.7. Final Attempts to Save Nupedia20.8. Conclusions
21.1. Sports Equipment Innovation by Users and Their Communities21.1.1. The User Innovation Process in Three Sports21.1.1.1. Discovery through use21.1.1.2. Communities: cooperation among users21.1.1.3. Commercialization21.1.2. How Important Is Community-Based Innovation in These Sports?21.1.2.1. Product origins: first-of-type innovations21.1.2.2. Major improvement innovations21.2. Community-Based Innovation and Development: An Even Broader Phenomenon21.2.1. The Automobile21.2.2. The Personal Computer21.2.3. User Firms in the 18th Century Iron Industry21.2.4. Amateur Astronomy21.3. Reframing: Where Does Innovation Come From?21.3.1. Building and Preserving the Intellectual Commons21.3.2. Firm Strategy21.4. Conclusion21.5. References
22.1. The Empirical Problem Set: What Are We Aiming At?22.2. The Theoretical Problem: How Is Knowledge Distributed?22.3. Design Principles for a Referee Function22.3.1. Weighting of Contributions22.3.2. Evaluating the Contributor Versus Evaluating the Contribution22.3.3. Status Quo Versus Change Bias22.3.4. Timing22.3.5. Granularity of Knowledge22.3.6. System Failure Mode22.3.7. Security22.4. What Should We Do Differently?
23.1. The Origins of Slashdot23.2. Slashdot in the Early Days23.3. The Slashdot Effect23.4. Trolls, Anonymous Cowards, and Insensitive Clods23.5. Columbine23.6. Slashdot Grows Up23.7. September 1123.8. Conclusion
A.1. The Open Source Definition, Version 1.9A.1.1. IntroductionA.1.2. 1. Free RedistributionA.1.3. 2. Source CodeA.1.4. 3. Derived WorksA.1.5. 4. Integrity of The Author’s Source CodeA.1.6. 5. No Discrimination Against Persons or GroupsA.1.7. 6. No Discrimination Against Fields of EndeavorA.1.8. 7. Distribution of LicenseA.1.9. 8. License Must Not Be Specific to a ProductA.1.10. 9. License Must Not Restrict Other Software
B.1. The BSD LicenseB.2. The GNU General Public License (GPL)B.2.1. Version 2, June 1991B.2.2. PreambleB.2.3. Terms and Conditions for Copying, Distribution, and Modification B.2.4. NO WARRANTYB.2.5. How to Apply These Terms to Your New ProgramsB.3. The Sleepycat LicenseB.4. The Creative Commons LicenseB.4.1. Attribution-NonCommercial-NoDerivs 2.5B.4.1.1. Attribution-NonCommercial-NoDerivs 2.5B.4.1.2. License
C.1. Simple SolutionsC.2. Why Kids Kill

Content preview from Open Sources 2.0

Chapter 3. A Tale of Two Standards

Jeremy Allison

It was the best of protocols, it was the worst of protocols, it was the age of monopoly, it was the age of Free Software, it was the epoch of openness, it was the epoch of proprietary lock-in, it was the season of GNU, it was the season of Microsoft, it was the spring of Linux, it was the winter of Windows....

Samba is commonly used as the “glue” between the separate worlds of Unix and Windows, and because of that, Samba developers have to intimately understand the design and implementation decisions made in both systems. It is no surprise that Samba is considered one of the most difficult Free Software projects to understand and to join, outclassed in complexity only by the voodoo black art of Linux kernel development. Samba really isn’t that hard, however, once you look at the different standards implemented in the two systems (although some of the decisions in Windows can cause raised eyebrows).

In developing Samba, we’re creating a bridge between the most popular standards currently deployed in the computing world: the Unix/Linux standard of POSIX and the Microsoft-developed de facto standard of Win32. In this chapter, I will examine these two standards from an application programmer’s perspective. In doing so, I thought it might be instructive to look at the reasons why each of them exists, what the intention for creating the particular standard might have been, and how well they have stood the test of time and the needs of programmers. ...