1. What Makes Open Source Projects Work Andrew Stellman Stellman & Greene Consulting http://www.stellman-greene.com/opensource

2. 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

3. Author of…

4. This presentation is open source You can download the presentation here: http://stellman-greene.com/opensource Released under the GNU Free Documentation License http://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.

5. 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

6. 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

7. 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?

8. 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?

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

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

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

12. 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

13. Wiki example: KDE Developer’s Corner Source: http://developer.kde.org/documentation/

14. KDE Wiki: HOWTOs and FAQs Source: http://developer.kde.org/documentation/other/index.html

15. KDE Wiki: Project Management Source: http://developer.kde.org/development-versions/

16. KDE Wiki: Tutorials Source: http://developer.kde.org/documentation/tutorials/

17. KDE Wiki: kHello Tutorial Source: http://developer.kde.org/documentation/tutorials/khello/khello.htm

18. KDE Wiki: kHello Tutorial Source: http://developer.kde.org/documentation/tutorials/khello/khello1.htm

19. Other Developer Wikis

20. Mailing List Example: GNU Emacs Source: http://savannah.gnu.org/mail/?group_id=40

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

22. Scope Documentation Example: Plone Source: http://plone.org/products/plone/roadmap

23. Scope Documentation Example: Plone Source: http://plone.org/products/plone/roadmap

24. Coding Convetions Example: Eclipse Source: http://wiki.eclipse.org/index.php/Development_Conventions_and_Guidelines

25. Build Documentation Example: Mozilla Source: http://developer.mozilla.org/en/docs/Build_Documentation

26. User Documentation Example: GIMP Source: http://www.gimp.org/docs/

27. User Documentation Example: GIMP Source: http://docs.gimp.org/en/

28. User Documentation Example: GIMP Source: http://docs.gimp.org/en/

29. Screencast Example: Ruby on Rails Source: http://media.rubyonrails.org/video/rails_take2_with_sound.mov

30. 2. Quality Unit testing, functional testing and acceptance testing

31. 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?

32. Yes, it’s true. Source: http://hobocentral.net/blog/2006/12/28/wot-no-tests/

33. Quality Case Study: Mozilla Firefox Source: http://wiki.mozilla.org/Firefox3/Goals

34. Firefox: Code Review Source: http://www.mozilla.org/hacking/reviewers.html

35. Firefox: Unit Testing Policy Source: http://developer.mozilla.org/devnews/index.php/2006/11/06/toolkit-unit-testing/

36. Firefox: Performance Testing Source: http://wiki.mozilla.org/Performance:Tinderbox_Tests

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

38. Firefox: Test Policy Source: http://developer.mozilla.org/en/docs/QA

39. Firefox: Test Policy Source: http://developer.mozilla.org/en/docs/Bug_writing_guidelines

40. Firefox: Test Case Management Source: http://litmus.mozilla.org/index.cgi

41. Firefox: Defect Tracking Source: https://bugzilla.mozilla.org/

42. Firefox: Smoke Tests Source: http://www.mozilla.org/quality/smoketests/

43. Firefox: Community Test Day Source: http://wiki.mozilla.org/Mozilla_QA_Community:Firefox_2.0b1_Community_Test_Day

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

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

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

47. 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

48. 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

49. “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!

50. Q&A Andrew Stellman Stellman & Greene Consulting http://www.stellman-greene.com/opensource