[Insight-developers] Mature Open Source - Making Your Software Last a Decade (OSCON 2010)

[Luis Ibanez]

http://www.oscon.com/oscon2010/public/schedule/detail/13750

 Dave Beckett <http://www.oscon.com/oscon2010/public/schedule/speaker/61467>(Yahoo!
Inc.)
 1:40pm<http://www.oscon.com/oscon2010/public/schedule/full#s2010-07-22-13:40>
Thursday,
07/22/2010 <http://www.oscon.com/oscon2010/public/schedule/grid/2010-07-22>
 Community <http://www.oscon.com/oscon2010/public/schedule/topic/Community>
 Location: D137

The emphasis on modern open source and software development is agility, easy
to change and “commit early, commit often”. Over the long term, the founders
and developers of projects move in and out of their activity or interest so
change can slow. When a project starts to live for years with updates, what
are the ways that this can be made a success so that the users can continue
to trust and use the software? This presentation will discuss the ways that
the project can be organized, bug recording, testing, developer engagement,
tools, communications and encouraging activity can be used to make a
successful OSS project work over the long term.

Mature means not just that it exists for some time i.e. old, but it also
means it’s a well known thing. The bugs and quirks are visible and probably
have workarounds. Stability can be more important than the latest shiny
thing for some applications. Maturity is thus an advantage in some cases,
especially at lower levels of systems.

Maturing open source software has different challenges from mature
commercial closed source software:

   - The developers for OSS are usually motivated by “scratching an itch”
   rather than getting paid, so it is natural that they move on to other
   things.
   - Nobody can see if closed source code is rotting and becoming
   unmaintainable or out of date, but that’s easy with OSS. By sitting
   still, OSS can seem older.
   - OSS does tend to work best in infrastructure such as operating systems
   and lower levels of systems, so can become quite embedded and older versions
   live a long time
   - Generally you don’t know who is using OSS, and relying on it so if
   updates are needed, there is generally no good way to tell the users.

This presentation will discuss how the author dealt with mature OSS projects
such as how to make changes, communicate them and know when to stop using
lessons learnt on working with
libpng<http://www.libpng.org/pub/png/libpng.html>(1994-),
cairo <http://cairographics.org/> (2003-), redland
<http://librdf.org/>(2000-) and smaller
OSS projects, as well as how other large projects have dealt with it.

The structure will be:

   1. Introduction to the problem.
   2. Organizing a project for the long term.
   3. Communicating with users and developers.
   4. Developer engagement – finding and keeping.
   5. Getting help – using support organisations and sites
   6. Staying fresh – releasing often enough.
   7. Staying stable – testing.
   8. Exit strategies – know when to stop.
   9. Conclusion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20100706/c129c55f/attachment.htm>