Python - an Open Source Project

1
Python - anOpen Source Project

• Guido van Rossum
• CNRI
• guido_at_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_at_python.org
• for questions asked in private forum
• tutor_at_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
• Unixconfigure 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 (USA4)
• 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