• Subscribe

    Subscribe to This Week In Panospace by eMail.
    Subscribe in a reader
  • License

    Creative Commons License
    This work is © 2008-2012
    by Yuval Levy
    and licensed under a
    Creative Commons License.
  • Entries

    January 2008
    M T W T F S S
        Feb »
     123456
    78910111213
    14151617181920
    21222324252627
    28293031  
  • Archives

Understanding Software Development


We’re all used to changing products throughout our life. A 2008 Honda Civic has some improved features over a 2007 Honda Civic, which in turn is a big accumulated change over the 1997 model. Same with software. Honda’s engineers improve their prototypes daily until a cutoff date. Then the changes are released to production of the new models that eventually hit the show rooms. Similar things happen with software releases.

The biggest difference is what happens between releases. Drivers have to patiently wait for the new features in the next model. The code of Open Source software is accessible to everybody, anytime. To build it and publish a download link often takes just a few hours and the typographic skills to follow instructions such as these for Enblend or Hugin.

Such a prototype is called a snapshot. It has a limited shelf-life because it is unfinished business before release. It has not been thoroughly tested. Features are incomplete. Nasty bugs may hide inside. It is not for the general public’s consumption. It is for testers to give timely feedback to developers. As development moves forward the snapshot is left behind to stale.

Commercial developers release such snapshots less frequently than Open Source projects, and they do so with an embedded expiration date. No Open Source project known to me bothers with expiration dates, as they rely on the sense of responsibility of the users.

Misunderstandings arise when such snapshot are used for longer than their shelf-life. Improvements on software can be more frequent and more radical than on any physical product out there: only in the last ten days, the hugin repository has registered 50 significant changes, going from revision 2618 to revision 2668 as it is being polished up for release. Enblend had 29 significant changes in the last 20 days.

Some of these changes may be new features, some may be corrections of known bugs. And some may introduce new bugs – mistakes are inevitable where people are at work. This is why Version Control is considered to be best practice in modern software development.

Hugin r2668 is not the same as r2618, and Enblend cvs20071230 is not the same as cvs20080118 – they are like the same car model a few years apart.

So how should users deal with all of these changes?

There are three good strategies:

  1. Stay a user: wait patiently for the next supported release and you’ll have the new features, trouble-free, on your desktop.
  2. Become a good tester: whenever a snapshot is released, download it, try it, and give feedback immediately. Quickly, because in a few days the snapshot will be superseded and feedback based on it will be old news. Be patient and tolerant. Expect things not to work as they should.
  3. Become a builder: It’s the beauty of Open Source, the empowerment of the users to help themselves. Building your own binaries is rewarding as you’ll know to have the latest tool working on your desktop. Your feedback will be timely relevant and you’ll contribute back to the community and shape the development.

If you stay a user, you can’t go wrong. If you want to become a tester or a builder, stay clear of a few major pitfalls:

  1. When referring to the software, be very specific about the version. Referring to Enfuse CVS20071231 is not the same as referring to Enfuse 3.1 (release) or to Enfuse CVS20080118
  2. Don’t expect that the observations related to a snapshot in a specific context apply to the software, newer or older, in the general context. You may keep using a snapshot that works for you, but be aware that other people’s mileage varies a lot.
  3. Snapshots are unsupported, and it is good so. Always encourage snapshot users to move to the newest snapshots (or to the latest release) rather than stay with the stale ones.
  4. The value of feedback decreases very rapidly with time. If your snapshot is not recent, consider the feedback that has already been given on it before adding yours.

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s