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

What Makes Open Source Projects Work

Andrew Stellman

Stellman & Greene Consulting

http://www.stellman-greene.com/opensource

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:http://stellman-greene.com/opensource

Released under the GNU Free Documentation Licensehttp://www.gnu.org/licenses/fdl.txt

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. Documentation2. Quality and Software Process3. 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: http://developer.kde.org/documentation/

KDE Wiki: HOWTOs and FAQs

Source: http://developer.kde.org/documentation/other/index.html

KDE Wiki: Project Management

Source: http://developer.kde.org/development-versions/

KDE Wiki: Tutorials

Source: http://developer.kde.org/documentation/tutorials/

KDE Wiki: kHello Tutorial

Source: http://developer.kde.org/documentation/tutorials/khello/khello.htm

KDE Wiki: kHello Tutorial

Source: http://developer.kde.org/documentation/tutorials/khello/khello1.htm

Other Developer Wikis

Mailing List Example: GNU Emacs

Source: http://savannah.gnu.org/mail/?group_id=40

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: http://plone.org/products/plone/roadmap

Scope Documentation Example: Plone

Source: http://plone.org/products/plone/roadmap

Coding Convetions Example: Eclipse

Source: http://wiki.eclipse.org/index.php/Development_Conventions_and_Guidelines

Build Documentation Example: Mozilla

Source: http://developer.mozilla.org/en/docs/Build_Documentation

User Documentation Example: GIMP

Source: http://www.gimp.org/docs/

User Documentation Example: GIMP

Source: http://docs.gimp.org/en/

User Documentation Example: GIMP

Source: http://docs.gimp.org/en/

Screencast Example: Ruby on Rails

Source: http://media.rubyonrails.org/video/rails_take2_with_sound.mov

QuickTime™ and a decompressor

are needed to see this picture.

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: http://hobocentral.net/blog/2006/12/28/wot-no-tests/

Quality Case Study: Mozilla Firefox

Source: http://wiki.mozilla.org/Firefox3/Goals

Firefox: Code Review

Source: http://www.mozilla.org/hacking/reviewers.html

Firefox: Unit Testing Policy

Source: http://developer.mozilla.org/devnews/index.php/2006/11/06/toolkit-unit-testing/

Firefox: Performance Testing

Source: http://wiki.mozilla.org/Performance:Tinderbox_Tests

Firefox: Continuous Integration

Source: http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox

Firefox: Test Policy

Source: http://developer.mozilla.org/en/docs/QA

Firefox: Test Policy

Source: http://developer.mozilla.org/en/docs/Bug_writing_guidelines

Firefox: Test Case Management

Source: http://litmus.mozilla.org/index.cgi

Firefox: Defect Tracking

Source: https://bugzilla.mozilla.org/

Firefox: Smoke Tests

Source: http://www.mozilla.org/quality/smoketests/

Firefox: Community Test Day

Source: http://wiki.mozilla.org/Mozilla_QA_Community:Firefox_2.0b1_Community_Test_Day

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

http://www.stellman-greene.com/opensource