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:
- Stay a user: wait patiently for the next supported release and you’ll have the new features, trouble-free, on your desktop.
- 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.
- 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:
- 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
- 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.
- 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.
- 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.
Filed under: testers