Open Source Projects

• Led by Ted Leung
• Notes taken by Sheila Mooney

Open Source: Why and How

• Part of the mission of the foundation
  • Transparency
  • Cooperation
  • Governance
  • Commons
• Open source method of production
  • OSAF is part of the experiment about how this works
  • Can't compare with Firefox - they started with a base of something
  • Projects tend to be non-profit
• In the public interest

Apache

History

• Original version done at UofIllinois^? - httpd/NCSA
• Enough to be used by a group of people - adhoc group - Apache Group
• No pre-existing corp entity - early 90s
• About 1999 that they created the Apache Software Foundation
• Since then, since it's become more famous - more projects have been involved.
• Now they have about 60 projects.

Governance

• Committers, PMCs, members, board
• Decided by voting
• Oversight by PMCs, members, board
• Managemetn of infrastructure, PR, legal
• Many projects
• Chairperson of PM committee has absolute power over the project. Escalate to PMC chair.
• One project group that the PMC thought the community was out of wack so the PMC decided that all commits should be reviewed in public.
• Members of the foundation - elect the board. Drawn from base of committers. Members suggest people every year.
• They become members because they take an interest in the foundation as a whole.
• Board responsible for stuff like tax reporting.

• Voting
  • Considered a mechanism of last resort. Not used all the time. Try to resolve without a vote.
  • Not everyone has to vote. Not full voting consensus
  • Any committer can veto but you need to justify it.
• They have many more projects than us.

Misc

• Designated release manager - rotates
• They work with companies
  • Company comes and wants to get involve - devote developers. This may not line up with the interest of the project
  • Some people take Apache SW and rebrand it.
  • Some tension but try and find a way for this to work.
  • We can learn from them
• Little UI so they have no experience integrating dev and design process
• No paid staff

Mozilla

History

• Nescape commercialized browser -> open source -> Mozilla project
• Alot of hype - took a long time.
• Smaller version - better UI - Firefox

Governance

• Module ownership - they have the final say
• Staff involvement in conflict resolution
• Technical disputes resolved by CTO
• Non-technical disputes resolved by Mitchell
• Several projects, one flagship

Misc

• Releases - determined by Mozilla Staff
• UI design - Firefox designers
• Paid staff = Mozilla staff

Linux

• Alot of people contributed to Linux over a long period of time.
• Governance - Linus owns trademark - final say.
• A series of trusted lieutenants that will have responsibilities.
• A single very large project.
• Release process - not formal compared to other projects. No clear release objectives.
• No UI design
• No foundation, organization, paid staff. No central org with funding.

Python

• Guido started hacking on a program language - people got interested.
• Benevolent dictator.
• Good job of community sponsored initiatives
• Release process - somewhat predictable.
• Volunteers for release management.
• Clear set of ideals.

Eclipse

• Started as an IDE for Java
• 40 projects now
• Started on a non-profit foundation.
• Apache inspired governance.
  • Corporate participants - supply big development teams
• Board - seats for corporate and dev members
• Dues are paid
• Fulltime executive director
• EMO - Eclipse Management Organization
  • Councils that manage the various projects - release, PM, PPD functions.
• Lots of UI
• Lots of projects
• Planning council manages the roadmap and release process.
• Design handled by requirements council - like PPD
• Paid staff - no paid developers

Ubuntu

• Started by Mark Shuttleworth
• Similar start to us
• Governance
  • Code of conduct - behavior in the community
  • After 4-8 weeks of substancial contributions, you can apply to become a member.
• Developers are members
  • Primary contribution is code
  • Criteria for contribution
  • Need to have communication and social skills
  • Evidence of high work rate and productivity.
• Cannonical
  • Paid developers working on Ubuntu
• Teams - marketing, doc, kernal, ppc..etc
• Technical board - people appointed by Mark - 1 year term
• Community council - term is 2 yrs
• Similar to OSAF
  • BDFL
  • Technical board - ops team
• Release process - determined by tech board
• Design process - not much

OSAF

• Experimental in process - not really done before
  • Fulltime staff model
  • Full citizenship for design
  • Emphasis on end users

What we have today

• Apache style voting - last resort.
• General agreement model.
• Ownership - Mozilla style - owners may override vote results.
• Core team - intentionally undefined.
• Ops WG - determines priorities for OSAF staff while on OSAF clock.
• BDFL - Mitch.
• Additional governance mechanisms as necessary.

Practical Issues/Questions

• Who is our community?
• What are our commitments to them?
• Interacting with potential designers/developers - not just technical ability.
• Customer support

Comments

• Priscilla - Core team doesn't seem clear
  • Core team is clear for developers but not as clear for design, qa, doc writers, release management, PM.
• Mimi - As the size of the project grows, the governance model will have to change.
• Mitch influenced by wikipedia governance - community of trust and expectations.
• Mikeal - seems like we have alot of rules - lengthy discussions on list when going in a room with sm group of people would be quicker.
• Ted - Cosmo team doing pretty good. Ahead of desktop team in terms of community. As long as stuff is documented, then it's ok to have meetings, IRC discussions etc.
• Katie - sometimes in person meetings can be inefficient too. Techniques on the list can be more efficient.
• Bear - Mozilla - if you are a module owner, you don't need to get this reviewed if it's core to the code but you need to have this logged in buzilla - good commit comment (there is a paper trail).