Motors

Ever since my youngest age I was fascinated by motion. At least once a year my father would drive for two hours to take us to the Museum of Transport and I would wander around and dream. Dream of cars, trains, planes. And of space and telecommunication. Space was my favorite. So many good memories.

Almost everything alive needs a motor. No motives, no action. No learning without emotions. And projects need a motor to move forward as well.

Most motors known to me have cycles. Whether it is the four strokes cycle of the arguably most common engine out there – or the magnetic inversion of electric motors, most of them are powered by cycles, even seemingly continuous jet engines.

And Open Source projects have a motor too, and it need to be taken care of. There is a striking resemblance to the four strokes of the internal combustion engine: Intake, Compression, Power, Exhaust.

Intake

Powered by the starter or by the end of the previous cycle, a fresh charge of vaporized fuel/air mixture gets into the cylinder. Similarly, drawn by the dynamics of the project, new feature requests and potential improvement gets on the radar screen of the developers.

Compression

The piston rises, compressing the vaporized fuel/air mixture. Similarly, as the features start to develop in the code repository, the pressure rises from the public for a release with the new potential improvements.

Power

At the top of the compression stroke, the spark plug fires, igniting the compressed fuel. As the fuel burns it expands, driving the piston downward. Similarly, the difference between the current repository status and the previous release is so intense that it sparks activity – bug fixes and clean up driving a release.

Exhaust

At the end of the cycle exhausted fuel is pushed out of the cylinder to make space for the next fresh charge of vaporized fuel/air mixture. Similarly, at the end of the cycle the software is released and the project get back in neutral state, ready for the next cycle.

And again…

Being aware of these phases, and knowing where one’s skills can contribute, is paramount to successfully integrate and understand an Open Source community. Developers looking for a challenge enjoy particularly the Intake stage – that’s when dreaming is allowed. Early adopters will feel the pressure of the compression stage earlier, and will contribute bug reports and improvement requests. A spark is needed to transform the mixture into power; and to call bug fixers, translators, builders, writers into action. A project has no power without them. Last but not least, everybody is happy when the pressure is released; when the tarball is uploaded on Sourceforge; when they can relax and tap on each other’s back for a job well done.

Hugin-2009.4 has stalled. I will release the third release candidate soon, but we need some more power to fix at least one serious bug. Some more bug fixing. Maybe I was pushing forward too hard. I also had to meet another, private deadline November 2. It seems to have worked. I hope I’ll have a bit more time for Hugin in the coming weeks.