Built To Last

We all build (or rent or buy) a dwelling at some points in life. And we all have different standards for our dwelling depending on its purpose. We choose with greater care the family home for the next few years than the camping spot for the next week. And we are more tolerant of little annoyances such as a water leak in a camping tent that will be disbanded in a day or two, than in a house that is intended to stay solid for decades.

Similar rules apply to software. Building a Windows binary of Hugin is a matter of less than an hour once the toolchain is set up. And if that was it, I could simply put it online and satisfy these calls. But what if it starts to leak? Guess who will take the heat and comments of disappointed users?

Ideally, there is a whole quality assurance process between a build and a distributed package. Commercial companies spend hundreds of thousands of dollars on quality assurance for small incremental releases and still mess them up sometimes.

So if I want to release a new installer, after building, I take some time to do quality assurance as described here. It’s not perfect, but it is what is reasonable for such a volunteer effort, and it is time that comes at a cost to my other free time activities. It’s a trade-off.

Facing the trade-off between packaging for distribution a release candidate that will change, or building the Google Summer of Code projects of the students that we so carefully selected and that we are grooming to become the next generation of Hugin contributors, what would you do?

I made my choice. I am committed to our students and I owe it to them. If you want something specific from me, contact me and we can discuss your requirements. Often this boils down to an hourly rate and a deadline that fits with my prior commitments.