From Teaching Open Source

Contents 1 Introduction to the good, bad and ugly 2 Examples of good projects 2.1 Ubuntu 2.2 Fedora 3 Examples of bad projects 4 What defines bad 5 Notes

[edit] Introduction to the good, bad and ugly

First we'll scour the web for examples and study what classifies Open Source projects as good or bad. To me, good means a resource that is clear and simple to follow yet offers details about most every aspect. For example a person should be able to read it and within 10 minutes download the source, create a patch, and submit it.

[edit] Examples of good projects

The good examples share these traits:

• Easy to find a "Get Involved" (or similar) on the main page
• Defines different types of involvement (Docs, Dev, Bugs, ...)
• Plenty of information
• Describes common etiquette (Ex. Why someone may not respond in IRC...)

[edit] Ubuntu

• http://ubuntu.com/
• "Get Involved" is extremely clear and present

[edit] Fedora

• http://fedoraproject.org/
• Definitions of types are simple and fun (love the icons)

[edit] Examples of bad projects

For now I'll only speak of one bad example because I'm heavily involved with it so feel comfortable defining it as bad. It's the [PHP] project. Improving this situation is why I started this mission.

[edit] What defines bad

The bad:

• No clear "Get Involved" section on the main site
• No clear instructions anywhere about how to get involved

But it:

• Does mention how to use CVS: http://php.net/anoncvs
• Does refer to the bugs section: http://bugs.php.net/
• Does have a newish wiki: http://wiki.php.net/
• Does have a (although hidden) contribute page (sort of): http://www.php.net/cvs-php.php

[edit] Notes

This wiki entry is extremely incomplete and eventually will turn into an official page of the project. However, in the meantime please feel free to add ideas or [write Philip].