Transcript presentation source

Python - an
Open Source Project
Guido van Rossum
CNRI
[email protected]
Timeline
• 1989/1990 first code
• 1991 first release
• 1992 mailing list
• 1993 newsgroup
• 1994 first workshop
• 1995 website
• 1996 first books
• 1999 world domination?
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
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!
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 don’t care about bugs
in device drivers; they will get fixed. I
care about getting the interface right.”
User community
• Mailing lists, newsgroups
• You will get flamed
• Don’t get into every argument
• Encourage potential contributors
• Recognize “difficult” users
• Use private mail when appropriate
• Accept recurring arguments
– sign of new users flowing in
Special Interest Groups
• Encourage user groups with special
needs to help themselves
• Mailing lists are cheap!
• Doesn’t always work
– some topics just don’t go anywhere
• focus on concrete tasks, topics (cf. IETF
working groups)
– some topics have questions but no
answers
Separate help channels
• [email protected]
– for questions asked in private forum
• [email protected]
– self-help learning group
– still experimental
• not clear if it is sufficiently different
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 :-(
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
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
Packaging is important
• Most users give up if download +
install doesn’t succeed at first try
• Windows, Mac: installer
• Unix:configure; make; install
• Linux: RPMs
• Packaging can be done by others
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
Website
• Essential for users
• Can be a lot of work
• Add a search engine!
• Let users contribute
– topic guides
– HOWTOs
– SIG home pages