Open Source III GNOME, Apache,

Justin Enderle & Seth Holloway EE382V - Perry 02/19/2008 Papers

The GNOME Project: a Case Study of Open Source, Global Development , 2003. Author: Daniel German

Two Case Studies of Open Source Software Development: Apache and Mozilla , 2001. Authors: Audris Mockus Roy T Fielding James D Herbsleb GNOME Paper

Daniel German, the author, was an active contributor to GNOME from 1999-2001, GNOME Foundation member as of 2003

Introduction to GNOME organizational structure and design methods.

Information sources Personal experiences, "immersion study" CVS repository mailing list archives GNOME Overview

GNOME = GNU Network Object Model Environment

Started in 1996 by An alternative to KDE, which used non- for development

Collection of libraries to make a viable desktop alternative

Components Easy to use GUI environment 'Office Suite' of applications Tools, libraries and components for development and application Paper Highlights / Drawbacks

(+) Author is intimately familiar with GNOME (+) Nice introduction to GNOME and it's background (-) Author cites himself 3 times (-) Whole paper spent describing GNOME (-) No critical look at relevant SW engineering topics (-) Lacks detailed quantitative analysis of GNOME Apache/Mozilla Paper

Authors Roy Fielding was a primary author of HTTP Mockus is a SW engineer working at AVAYA Herblseb is a professor at CMU

Paper sets out to Characterize OSS development Compare to traditional software methods Describe prospects for OSS Data Sources

OSS CVS BugDB/ Commercial ECMS/SCCS Apache Overview

"A patchy" web server that is skillful and reliable in battle

Grew out of NCSA HTTPd 1.3

Apache HTTPd 2.0 was developed to improve modularization and portability

Serves most pages (~51%) on the Internet

Released under the Apache License (copyright)

Success spawned more work and led to Apache Foundation Apache Foundation Projects

Web servers HTTP server Tomcat Programming languages Perl TCL Build support Ant Maven Reusable code Xerces ... Mozilla Overview

Mozilla was the codename of Navigator and mascot

Mozilla was the integrated

Grew out of

Became too bloated and split into more-specialized projects Thunderbird SeaMonkey

Released under Mozilla License (weak copyleft)

Now, the Mozilla Organization and the Paper Highlights / Drawbacks

(+) Very well written (+) Knowledgeable authors (+) Great empirical study good rationale, accepted methodology, well known metrics, statistically sound (+) Amazing example of how to make your work into a paper (+) Important information about OSS (-) Long (-) Dry (?) The paper was written after both sets of data were analyzed... Did they really hypothesize before getting secondary data? :) Discussion Questions

Who uses products by Mozilla? Apache? GNOME? Discussion Questions

Does anyone contribute to open source projects? If so, what project(s)? Why? If not, why not? What is your dream project? Ways to contribute to OSS

How could an individual contribute to OSS? Ways to contribute to OSS

Write code Internationalize/translate Find and report defects Manage release Promote the product Provide technical support Document the code, development process, and usage Design the interface Provide artistic works Communication

What are the most effective ways to communicate in a highly distributed group? Communication Methods

Mailing lists

IRC

Web sites

Project-specific Conferences

Summaries periodically sent to mailing list Structure/Organization

How would you structure a large group consisting of project contributors and users? GNOME Organization

No single GNOME maintainer

Modularized architecture ==> Modularized development 76 modules of libraries and core apps in Spring 04 Modules have own set of maintainers, developers, time lines, and objectives.

Originally run as a pseudo legislature All contributors have a voice the 'floor' is the developers mailing lists Miguel de Icaza the 'constitutional monarch' and 'supreme court' GNOME Foundation

Corporate interest in GNOME success Red-Hat and SUN using for desktop environment Two companies ( and ) spawned to sell services

Large number of corporate contributors

Concerns that large number of industry contributors could use their votes to hijack the project

GNOME Foundation created in 2000 Mitigate industry influence Democratic process where community can have a voice GNOME decisions made in open and transparent way GNOME Organization

Release Team 6 month time-based releases Determine schedules and keep project on track Set and monitor test release dates Code freezes Version 2.4 Release schedule GNOME Organization

More than 500 people have write access to CVS repository

Top 10 account for 46% of total Modification Requests (MR's)

MR's per developer for Evolution GNOME Organization

Contributors more likely to join the project earlier than late, due to more glory and respect involved

Methods in place to help attract new contributors bug fixing TODO lists GNOME-love mailing list Active developers per month Apache Organization

Structured similarly to GNOME

Leverage users as developers and contributors

almost 400 developers total 3060 people submitted problem reports 306 people reported 2 PRs 85 submitted 3 1 submitted 32 458 individuals' reports led to changes 182 people worked on fixes Apache Organization

Top 15 developers 83% of MRs/deltas contributed 88% of added lines 91% of deleted lines Apache Organization

Top 15 Apache developers were more productive than top 15 commercial developers in other projects Apache Organization

Modular architecture facilitates distributed development Multiple people responsible for individual files Mutual trust amongst developers Code ownership is a matter of expertise Software Development Process

How would you develop software for open source? GNOME Process

Where is the guiding light? Vision provided by one or several leaders Reference applications, ex: Office Suite Mailing list discussions Prototypes Post-hoc additions

Maintainers largely responsible for breaking up module level tasks for individuals

Paper does not address influence of industry on requirements, or level to which above are influential Apache Development Process

All developers had outside jobs =>Needed decentralized decision-making abilities =>Apache Group (AG) consists of core members

General Process 1. Find work (bug or new functionality) 2. Determine developer 3. Identify solution 4. Develop and test locally 5. Present change to AG 6. Commit code, update documentation Apache Development Process

General Process 1. Find work (bug or new functionality) Bugs submitted to mailing list, BugDB,

2. Determine developer Core issue: core developer Other issue: area expert ... newbie

3. Identify solution Discuss alternatives on mailing list Apache Development Process

General Process (continued) 4. Develop and test locally Left up to owner

5. Present change to AG Code approved before release Development branch: reviewed after commit Stable release: reviewed before commit

6. Commit code, update documentation Left up to owner Discussion Questions

Is OSS architected better than commercial products? Does the success of all software depend on the architecture? Are successful OSS projects "better" architecturally than their commercial competitors? Which has more defects? How quickly are defects fixed? Software Quality

What is the level of software quality in open source projects? Apache Quality

Expect more bugs in Apache due to widespread usage Competitive with industry Apache Quality

50% of defects are resolved in 1 day 75% in 42 days 100% in 500 days Competitive with industrial development Industry affiliation

For OSS, what are the risks/rewards of close collaboration with industry affiliates? GNOME Industry Affiliation

Red-Hat and Sun interested in GNOME to enable viable desktop alternative

Companies spawned to sell services around GNOME Ximian founded by Miguel de Icaza and other GNOME founders

Top 10 most active developers (as proportion of MR's) shown to be affiliated with Ximian employees or consultants

Industry employees often responsible for tasks undesirable to volunteers Project coordination Testing Documentation Bug fixing Apache/Mozilla Industry Affiliation

Both have ties to industry

IBM WebSphere application server uses Apache

Google, IBM, others employ Mozilla committers Lessons Learned

Are there any lessons that commercial software companies can learn from open source? Lessons "Learned" from GNOME

Potential points of benefit Flatten the organization Multiple types of communication Treat developers as partners Regularly scheduled co-located meetings Task forces Procedures for conflict management Modularize Ask developers to document daily contributions

States FOSS significantly different than commercial, so these may not apply. Does not enumerate differences or how they may effect lessons learned. Apache/Mozilla Conclusions

H1 : Open source developments will have a core of developers who control the code base, and will create approximately 80% or more of the new functionality. If this core group uses only informal ad hoc means of coordinating their work, the group will be no larger than 10 to 15 people. H2: If a project is so large that more than 10 to 15 people are required to complete 80% of the code in the desired time frame, then other mechanisms, rather than just informal ad hoc arrangements, will be required in order to coordinate the work. These mechanisms may include one or more of the following: explicit development processes, individual or group code ownership, and required inspections. Apache/Mozilla Conclusions

H3 : In successful open source developments, a group larger by an order of magnitude than the core will repair defects, and a yet large group (by another order of magnitude) will report problems. H4 : Open source developments that have a strong core of developers but never achieve large numbers of contributors beyond that core will be able to create new functionality but will fail because of a lack of resources devoted to finding and repairing defects. Apache/Mozilla Conclusions

H5 : Defect density in open source releases will generally be lower than commercial code that has only been feature-tested, that is, received a comparable level of testing. H6 : In successful open source developments, the developers will also be the users of the software. H7 : OSS developments exhibit very rapid responses to customer problems. Discussion Question

What determines the success of open source projects in the real world? Discussion Questions

In the future will competing open source projects spread scarce resources too thin? Has sourceforge (and other OSS containers) succeeded in spreading open source or made it more difficult to find useful projects? Discussion Question

Given the quality and breadth of open source projects, how can companies sell software? How Companies Sell Software

Companies support their product Users can (potentially) receive assistance Tangible entity to blame when software fails Enterprise software requires greater security and compliance Existing contracts bundle software and hardware People become familiar with a family of products that were pre-installed on their PC Products are developed around dominant software systems OSS lacks awareness in general public/OSS is not in stores OSS leaders do not play golf OSS versus Commercial Development

OSS Commercial -"Many eyeballs implies shallow -Limited testing resources bugs" -Project plan set months in -Updates are published as soon advance as they are implemented -Products involve marketing, -No hard schedule sales, documentation, -Patches and features are not production, hardware, ... sold as features -Assigned to project -Choose where time is spent -Fear of losing your job -No/little income possible -Career advancement concerns -Little accountability (limit involvement in a domain) -Trains thousands of developers The End is Nigh

You will now clap and mean it!

?/!