With the increased pace of development, added features, and improved stability, Hugin has become more visible and has got more attention and love from potential users, and of course they have needs and wishes.
One recurring user request is: “why don’t you make binaries available?” John Riley argues for a “concerted effort to create binaries”, saying that Hugin “deserves a much wider audience than those who are willing and/or able to build it from source” and that “making it more accessible would increase its visibility, which could get more people interested in contributing”.
No doubts that binary distributions would be nice. How do they fit in the plan? What is the status of the project? Of the binaries? What are the priorities?
Most contributors to Hugin are volunteers. The rule number one is that there is no master plan. Well, I do have my plan, but I can not impose it on others; and others can’t impose their plan on me. Each contributor decides what is right for him, set his own priorities and contributes what he wants. If the contribution makes sense other contributors will adopt, follow, join, contribute.
I like to think of contributors as a free-flowing fluid on the project, like water on Earth. The fluid is naturally attracted to valleys where it forms rivers and lakes. Its passage shapes the landscape.
Controlling the fluids would need expensive barrages. Most often not a practical proposition. Project administrators only decide what is on Sourceforge and even this is not control: The software is Free. No barrier can prevent the fluids from flowing in an alternate direction and if that direction is more attractive, others will follow. It’s purely meritocratic.
Hugin is undergoing major change. Growth has exposed the limits of the previous structures, and we had to adapt to the new dynamic.
When I first got involved with Hugin three years ago, I found the learning curve extremely steep. We needed to make it more attractive to contributors. In response to the difficulties encountered by the Google Summer of Code students the project reacted with SDK and documentation. Hugin has become more accessible for contributors. We see the result with new contributors coming on board almost every month (and without the incentive of a Google internship). Their contributions pose new challenges.
Last year we integrated four major contributed features: celeste; fast preview; batch processor; and new projections.The integration resulted in a development freeze for much of 2009, until the 0.8.0 release last July.
In the meantime, the queue of new contributed features waiting for integration had doubled:
- GPU-stitching (to use modern hardware for faster stitching, integrated in 2009.2.0);
- lens calibration (to develop a better mathematical model for the lens geometry, integrated in 2009.4.0 but not ready for practical use);
- deghosting for enfuse (to reduce ghosts when merging stacks of images with enfuse, integrated in trunk and scheduled for release after 2009.4.0);
- CPclean (to prune bad control points by statistical method, integrated in 2009.4.0);
- Auto-crop (to reduce the blank areas around the image);
- New layout mode (to improve the handling of exposure stacks);
- XYZ-transform (to improve geometric positioning when the images are not taken from precisly the same no-parallax-point);
- Masking in GUI (a Google Summer of Code 2008 project that we’re still studying how to integrate).
And there are plenty of small incremental improvements here and there that would not have happened if we were in a freeze.
Extrapolating the past, we’d be frozen until 2011. This would effectively kill the project. I introduced parallel development to solve the bottleneck, and I hope we can work through most of the back log before the end of the winter.
There is a cost to parallel development: desynchronization. And the less glamorous areas of the project suffer particularly. Building binaries for distribution is such an area.
The Hugin project is committed to release source code that builds on a wide variety of platforms. The creation and distribution of binaries is left to the users’ communities. Of course we are users ourselves, and we do build binaries, mostly for testing purposes and only on our respective platforms. Our contribution to the distribution process is mostly documentation, because building for self-use and building for distribution are two completely different things, despite a common set of underlying steps.
We stop at the source code for many reasons. Primarily: limited access to all the platforms; limited resources; limited time. Building for distribution requires extra care (quality assurance) and extra steps that are critically important to make the difference between a good distribution and a dysfunctional one. Starting from a fresh source tree is strongly recommended to build a proper distribution. A developer’s source tree is seldom fresh. It contains the traces of the developers work, and this has the potential to contaminate the build process.
One of my activities over the past three months, as I took charge of our release process, was to liaise with downstream distributors to help them produce better distribution in the hope that new versions of Hugin will trickle faster down the distribution channel to the end users. The result:
- The Hugin FreeBSD port is now easier to maintain and maintainer Vasil Dimov tracks recent releases closely.
- The Hugin Gentoo Linux ebuild is kept up to date by Thomas Pani, Gentoo maintainer.
- Coordination with Andreas Metzler and the maintainers team at Debian resulted in the clean up of some outstanding issues and better support of that plattform and its derivates, including Ubuntu. Unfortunately Hugin 2009.2.0 did not make the cut for Ubuntu 9.10, which has Hugin-0.8.0 available through it’s package manager.
Of course this is of little interest for people who do not use FreeBSD, Gentoo, Debian, Ubuntu. And the reality is that the majority of users are still on Windows. Systems without package managers (Windows and OSX) add additional effort / complexity to the build and distribution of binaries. Nevertheless, Harry van der Wolf, supported by some other Mac users, provides unofficial OSX binaries on a regular basis. And for Windows, I have recently guided a few users through parts of the build process. Unfortunately none of the resulting Windows binaries is stable enough to be declared official.
Given all the back-log of features to integrate, and the consequent knowledge that the current release of Hugin is short lived and a newer, better one is just around the corner, why put the effort to produce a Windows installer that will be obsolete soon? Of course ideally the installer should track closely the development, but it seems to be too much effort at the moment. At some point, the gap between the installer and the code will be deep enough to attract more attention, and somebody may be motivated to provide a Windows installer.