• What is open source software?
• OSS key practices
• Who does what and when?
• Some things to notice about OSS

• Software is open source software if it is distributed to users under an open source license.
• The Open Source Initiative defines an open source license as granting rights to at least do the following:
  • Redistribution: you may give or sell it (including source) to someone else
  • Source access: you may view the source code
  • Derived works: you may modify the source and distribute the new version under the same license
  • Non-discrimination of users: e.g., not limited to non-commercial use only
• Key concepts:
  • Empower users to do what they want to do with the software, not just what the original author wants to happen.
  • Development of software is decoupled from economic rewards.
  • Transparency. All project information is available for public review.
  • Interoperability. Many OSS projects emphasize compatibility with standards so that users may use various products together.
• Open source itself is not a software process. But, several key practices are often seen in open source software development projects.

License

Each open source project uses a software license that fits the OSI rules. There are many OS licenses that are slightly different. The biggest difference is between "viral" and "non-viral" licenses.

• E.g., GPL is viral: when software under the GPL license is combined with other software, the entire result must also be under GPL.
• E.g., BSD is non-viral: when software under the BSD license is combined with other software, that other software need not fall under BSD.

Project founder

A person or company that starts an open source project and usually tries to attract contributions from volunteers.

Project member / Committer

A person who is trusted to make changes to the OSS project's source code repository.

Contribution

Users are welcome to explain their needs to help the OSS project gather better requirements. When users encounter defects, they are encouraged to contribute bug reports. If users want to fix or enhance the product, they are welcome to contribute that code back to the project. Of course, developers who are members of the project make the decisions as to what is done with these contributions.

• Universal, immediate access to all project artifacts
  • Project website, mailing list, and CVS available 24/7
  • No secrets about project status, defects, upcoming plans, etc.
  • Allows developers to work from any location
• Staff projects with motivated volunteers
  • Each developer understands the requirements deeply
  • Developers take pride in their work, generally are not rushed
  • Cannot easily staff-up the project
  • Sometimes hard to say "no" to a contributed feature
• Work in communities
  • Watch how other open source projects develop software
  • The same tool set is used by all projects in community
  • Peer pressure to reuse other projects in same community
• Follow standards to validate project and enable reuse
  • It is easier to agree on standard than to define a new one
  • Standards give users a choice of clients
• Practice reuse to manage project scope
  • Reuse helps OSS projects reach first release fast
  • Replace working code with external reusable libraries
• Support diversity of usage and plurality of authorship
  • Cross-platform and internationalized
  • Add features that broaden the appeal of the product, attract more users and contributors
  • Encourage users to "scratch an itch"
• Release early, release often
  • Get first release out fast to attract users and contributors
  • No overhead for burning CDs or updating marketing materials
• Place peer reviews in the critical path
  • Only committers may change the source code, other contributors must give their code changes to committers for review
  • Project members may review each change after it is made

For more on OSS practices, and discussion of OS software engineering tools, see my book chapter on it.

• Open source is not a process, so there is not much guidance on who should do what and when. But here are some things that are commonly seen.
• Features and defect fixes can be scheduled for a specific release and several releases may be planned, but only the sequence and scope of the releases is considered, not their calendar dates.
• The project founder puts together a very early working version of the system. This version helps to express the idea of what the full system should do. This helps make up for incomplete requirements documents.
• Project members review commits immediately after they happen and make comments about design and programming style.
• Code is the central artifact. Usually there is not much effort spent on design documentation. Instead, design ideas are discussed on mailing lists. Eventually, someone may write a developers' FAQ to explain key design decisions.
• The OSS version of synch-and-stabilize is even/odd release numbering. In some projects, even-numbered releases are "stable" releases with more polish, whereas odd-numbered releases are "experimental" or "developer" releases.
• The OSS project keeps going as long as users see potential improvements and become contributors. E.g., emacs is on version 21.2 after about 20 years.

• OSS works best when:
  • There is a lot of overlap between the population of users and potential contributors, OR
  • A corporate sponsor backs an OSS project as part of a larger business plan, OR
  • The OSS product is largely a copy of an existing commercial product, OR
  • The OSS product is mainly an implementation of an existing standard
• Some OSS practices can be applied to traditional processes.
  • Universal, immediate access
  • Transparency
  • Frequent code reviews
• OSS is most like the Collaborative or Global software development process model:
  • OSS projects are flexible in their use of resources and partnerships
  • Developers can work from anywhere in the world
  • Managers can oversee projects anywhere in the world