1. Python - an Open Source Project Guido van Rossum CNRI guido@python.org

2. Timeline 1989/1990 first code 1991 first release 1992 mailing list 1993 newsgroup 1994 first workshop 1995 website 1996 first books 1999 world domination?

3. Factors for success Things you cannot control –Product category, target audience, competition –Your own personality Things you can control –Open source –Contribution policy –Presence in user group –Release quality

4. Common sense Communicate with users –multiple communication channels: FAQs, mailing lists, newsgroups, websites, chat rooms... Give credit to contributors –if you want contributions! Use volunteers as lieutenants –delegate what you can!

5. Provide extensibility Reduces user pressure for changes Possibly at several levels –in Python: 2 major extension levels (Python, C/C++/...) Take care to define & document extension interfaces Linus Torvalds: I dont care about bugs in device drivers; they will get fixed. I care about getting the interface right.

6. User community Mailing lists, newsgroups You will get flamed Dont get into every argument Encourage potential contributors Recognize difficult users Use private mail when appropriate Accept recurring arguments –sign of new users flowing in

7. Special Interest Groups Encourage user groups with special needs to help themselves Mailing lists are cheap! Doesnt always work –some topics just dont go anywhere focus on concrete tasks, topics (cf. IETF working groups) –some topics have questions but no answers

8. Separate help channels python-help@python.org –for questions asked in private forum tutor@python.org –self-help learning group –still experimental not clear if it is sufficiently different

9. Bug report mechanism Most bug tracking software sucks Many reported bugs will be: –duplicates –fixed in newer release –user errors –surprising features –documentation bugs –unreasonable feature requests Known bugs list, TODO list etc. are never enough :-(

10. Contributions Encourage well-packaged contributions –e.g. context diffs with clear description and motivation Be prepared to refuse contributions Recognize good contributors Provide contributor training

11. Releases Quality controlled stable releases –to build user trust Development releases –for active contributors –to help discover bugs in time Hard question: what to put in release, what to leave out –reconsider over time

12. Packaging is important Most users give up if download + install doesnt succeed at first try Windows, Mac: installer Unix:configure; make; install Linux: RPMs Packaging can be done by others

13. Documentation Can never have enough! Tuturials and reference manuals Separate developer documentation Multiple formats HTML (on-line & downloadable) Postscript/PDF for printing (US+A4) source (latex/SGML) Emacs info, MS Help,... Can be managed by others

14. Website Essential for users Can be a lot of work Add a search engine! Let users contribute –topic guides –HOWTOs –SIG home pages