What Makes Open Source Projects Work Andrew Stellman Stellman & Greene Consulting

Who I am… I’m a: •Software engineer •Programmer •Author of books and articles •Process improvement specialist •PMP-certified project manager •Open source project maintainer

Author of…

This presentation is open source You can download the presentation here: Released under the GNU Free Documentation License Copyright © 2007 Stellman & Greene Consulting, LLC. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

Why look to open source? •Even now, there’s still a software crisis •Less than a third of software projects are successful •Many prominent open source projects succeed under conditions that would sink most corporate projects

The story so far •“What Corporate Projects Should Learn from Open Source” – 2/26/06 •Five basic principles: –Tell the truth all the time –Trust the team –Review everything, test everything –All developers are created equal –The fastest way through the project is to do it right

We want details! •Great on principles, light on specifics! •Successful open source projects: –Deliver high quality –Bring diverse, volunteer-heavy teams together without ever holding a single meeting –Encourage wide participation –Keep their user base highly satisfied •How do they do it?

Highly Motivated Developers •Volunteers are naturally excited •Team members are doing work that they want to do, rather than work they must be paid to do •There’s no schedule pressure, so they don’t cut corners. •Everyone’s public reputation is on the line The team wants the job done right! How does that change the way they work?

When developers know they need to do the job right, they use better practices!

How They Do It Successful open source projects use practices that improve: 1.Documentation 2.Quality and Software Process 3.Code and Architecture

1. Documentation Tools, techniques and practices for writing down the things that you need to run your project

Wikis and Mailing Lists •Documentation is a communication tool •Open source projects use documentation tools that are focused on communicating •Wikis are popular because they are optimal distribution, collaboration and revision history •Mailing lists are useful for keeping track of all communications, and serve as a record

Wiki example: KDE Developer’s Corner Source:

KDE Wiki: HOWTOs and FAQs Source:

KDE Wiki: Project Management Source:

KDE Wiki: Tutorials Source:

KDE Wiki: kHello Tutorial Source:

KDE Wiki: kHello Tutorial Source:

Other Developer Wikis

Mailing List Example: GNU Emacs Source:

Documentation •Well-managed software projects require well-maintained documentation: –Scope documentation –Code and API documentation –Build documentation and release notes –User documentation –Screencasts

Scope Documentation Example: Plone Source:

Scope Documentation Example: Plone Source:

Coding Convetions Example: Eclipse Source:

Build Documentation Example: Mozilla Source:

User Documentation Example: GIMP Source:

User Documentation Example: GIMP Source:

User Documentation Example: GIMP Source:

Screencast Example: Ruby on Rails Source:

2. Quality Unit testing, functional testing and acceptance testing

Software Process and Quality •You can’t test quality in at the end •Successful open source projects plan quality into the entire software lifecycle: –Code Review –Automated unit tests –Performance testing –Continuous integration –Software testing and test case management –Smoke tests –Organized user test events Do open source teams really do this?

Yes, it’s true. Source:

Quality Case Study: Mozilla Firefox Source:

Firefox: Code Review Source:

Firefox: Unit Testing Policy Source:

Firefox: Performance Testing Source:

Firefox: Continuous Integration Source:

Firefox: Test Policy Source:

Firefox: Test Policy Source:

Firefox: Test Case Management Source:

Firefox: Defect Tracking Source:

Firefox: Smoke Tests Source:

Firefox: Community Test Day Source:

3. Code and Architecture A few important techniques that help with teams

Code and Architecture Practices •Module-based architecture •Continuous integration •Code library distribution •Automated unit testing •Test-driven development

So what now? How you can use the tools, techniques and practices that make successful open source projects work

Contracting is like open source •If you work at a contractor or vendor, your team is similar to an open source team: –Geographically distributed virtual team –Higher turnover of staff –Need to quickly ramp up new team members –Usually work with a strict process

What about in-house teams? •Of course they can benefit! –Practices developed for virtual teams work BETTER for co-located ones –Quality improvement is easier in-house –Test-driven development, continuous integration and other development practices are always a good idea

“So where do I start?” •Build a wiki and start populating it •Start building unit tests for the next new class to be constructed •If product scope isn’t documented, write it down immediately! •Set up automated build procedures and a continuous integration system •Talk to your team members and get them fired up about using open source practices!

Q&A Andrew Stellman Stellman & Greene Consulting