Low Hanging Fruits vs. Seeding a Tree

Low hanging fruits are a tenet of Open Source:  work smarter rather than harder; reuse as much code as possible;  release early and often.  This way spare-time contributions bear fruits quickly.  And yet there are situations when the fruits are not low hanging.  Actually, the fruits do not exist yet.  Somebody has to plant the initial seed and help a tree grow for it to bear fruits.

Seeding and growing takes time.  A Google Summer of Code project is an opportunity for such a seed.  Technically it is a 480 hours project all in one chunk, compared with the average spare-time contributor that puts in 2-4 hours per week and would take 2-4 years to clock that same quantity of hours (not considering the losses due to the pauses between the chunks of work).

So while in most cases the tenet of focusing the effort on the low hanging fruit still holds, it is important not to miss unique opportunities to add new seeds to a project.

Two Different Worlds

As Libre Graphics Meeting (or LGM as it is known amongst insiders) is getting closer, projects and contributors are looking for sponsors.  Even in the Free world, conferences are expensive.  I’ve added the pledgie link to Hugin’s homepage and I believe other Free software projects have done the same.  And in the community, people are musing about corporate sponsorships.

My own humble opinion is that asking Linux vendors to sponsor Libre Graphic Software is like asking Walmart to enter the trucking business.  Those are two completely different worlds.  Sure they do business (Walmart needs to truck its goods), but the driving factors are different, the cultures and people are different, and they are good to each other at a distance.

Similarly, the Linux vendor are in the computing infrastructure business, not in the graphics business, and while they have some graphics needs (like every business); and we have some computing needs (like every business), there is no natural fit for more integration than just “using” each other’s products.

The right sponsorship to Libre Graphics would come from businesses whose core competence is the image.  A print-shop for Scribus (I can’t stress enough how good a print shop is Mardigrafe – if you have printing needs in Montreal, talk with Louis, who happens to be one of the driving forces behind LGM and Scribus).  A movie studio for Blender.  An advertising agency for Gimp.  A news agency for RAWstudio.

It does not always work.  Remember Cinepaint?

For it to work, the mentality within the industry must change. It is only when box vendors realized that Linux gives tham a competitive edge that they started funding it.  First as tactical counterweight to Microsoft.  Only in a second stage some of them realized that adopting Linux (rather than merely using it to put pressure on Microsoft) is a viable and profitable strategy, and now we have Android (Linux based) tablets.

Similarly, the initial pitch to the graphic design industry would be to put tactical weight on Adobe, to push Adobe into moving forward with features that appear first as “prototypes” in Free software; and into lowering its prices.

At some point, some will realize that adopting Libre Graphics is actually good for their bottom line.  And the small shop that pays $20.000/year on Adobe licenses now will get the same work done with $0/year of Libre Graphics software.  With such a competitive advantage they might consider plugging some of these savings back into what amount to R&D expenses on features that help their bottom line, as opposed to licensing fees that are just taxing their business.

Contribute

I’ve been recently approached by a user looking for advice:

“I’ve never contributed to an open source project before, so what’s the procedure for contributing. Should I share a patch with some others to test before committing? Now that I have a fix, I don’t know what to do with it!”

Have a Look Around.

Welcome to the world of open source. Every open source project has their own way of working and some are more formal than others. You want to find your way around.  For Hugin, I have formalized a community charter a while ago.  Observe how the project works and ask on the public communication channels how to contribute.

Make it Relevant, Persistent, Known.

For your contribution to be successful, you want to make it relevant, persistent, and known.

Relevance is context. The context of your contribution is most likely the project’s codebase. Make sure your contribution relates to a recent version of the code, and that it can be easily shared and applied.  In our case, assuming that you have the project’s Mercurial repository on your hard drive, make sure that your modifications are relevant to the most recent version of the code base and produce a standardized patch that is easy to apply:

hg pull
hg up default
hg diff > bugfix.patch

Next, find out what the project uses to track issues.  Issue trackers are used for persistence.  Hugin’s issue tracker is on Launchpad.  Whether your patch fixes a bug or adds a new feature, make sure that it is in the issue tracker.  If the bug is already known, add your patch to the existing bug report.  If it is new, file a new ticket.

Last but not least, make your contribution known.  Introduce yourself into the project’s communication channels and make the public aware of your tracker entry.  The ball is now in the project’s camp.

And now?

Now it is time to receive feedback.  Your contribution will be peer-reviewed.  Chances are that you will get some.  Senior code contributors may comment on your coding style or on the details of the implementation.  Bleeding-edge users may integrate your contribution into their self-built binaries and report test results.  Your contribution has taken the path toward integration and you have become a contributor.  Don’t forget to add yourself to the author’s list.  Thank you for helping make Hugin better.

Itches and Scratches

I feel numb. All of the itches I had, that motivated me to contribute to Hugin, are frozen, anesthetized by a few remarks, who seems to represent the silent majority of users – at least of Windows users.

A few excerpts of his accusations:

1. hugin distribution politics is far from the high quality of the software.
2. Did you do anything better?
3. you don’t make it easy for me (and for others) to keep up this sympathy [for Hugin]. And I fear others aren’t as patient as me. In other words and if you still didn’t get it: I think you distract people from using or even trying hugin.
4. And BTW.: I won’t read any longish reply to that. If it is as short as  “I’m sorry”, I will…

The only thing I am sorry about is wasting my time on such apparently useless things as:

• getting the project accepted to Google Summer of Code in 2007, resulting in a 75.000 US$ donation from Google over three years (thank you!) that enabled 15 student-summer projects on Hugin and related project; and more in-kind sponsoring from industry leaders Agnos and Nodal Ninja (thank you again) that helped motivating students and mentors beyond the Google Summer of Code. Running the team during two of the three participations and mentoring two students.
• Mentoring other contributors.
• Writing the Windows installer script for Hugin-0.7.0 when I was a user of that platform.
• Re-engineering the project to encourage participation, resulting in an amazing documentation effort by users of all platforms.
• Re-engineering the project’s repository, streamlining development and integration of new features, releasing Hugin-2009.2.0 in record time (and 2009.4.0 is around the corner, all of this without freezing development).
• A few bug fixes, and little features. There was more work in progress, but at the moment I don’t feel like touching it. It’s in a tarball in a remote corner of my disk for now.
• Organizing a Hugin art exhibition.

Actually, looking at the list I don’t feel sorry at all about what I did. I am sorry for those who ask if I did anything better. I wish I did not have such a short fuse, but overall I feel good. New, different itches are coming back to me. The numbing is temporary. I can do other things with my free time in the Free world. Life beyond Hugin.

The thing I like most about Free software is “scratch your own itches”: Contribution is purely voluntary, everybody does what they want/like to do; with little exceptions (as in: being hired or otherwise paid to do a job) there is no obligation.

To me personally, my first motivation is to learn. Life is an exciting journey and there is always something new to learn. The day I will rest my head on the pillow without having learned something new will be a sad day for me. Flat EEG.

Corollary: I like to move on to new things once the concept is proven. Not only the fuse is short. Others can pick it up from here. If my byproduct is helpful to them, good for them. If it isn’t, it’s OK for me too.

Next, I’m in it for the social fun. I’m an eccentric and I seem to find more people with comparable life experience, who are sometimes like-minded, among Open Source contributors. However social fun does not mean pleasing others. In a business relationship I will please my customers, my boss, my co-workers. In a social fun relationship, I’ll do what I enjoy doing, with people that accept me as I am. Not that I won’t occasionally scratch somebody’s else itch. In the end this is my free time and I dispose of it as I please.

Last but not least I’m in it to expand my toolbox, on two levels: as a photographer I’m pragmatic about Open Source and think that the tools complement nicely and sometimes substitute licensed proprietary tools. GIMP is unlikely to replace Photoshop in my workflow any time soon, but it has some unique features that Photoshop does not match. So I happily use both. As an apprentice coder, I’m all for Open Source. The method is better than anything else I have read or seen. But maybe that’s just because the superior proprietary method is such a well-kept secret? I doubt it.

Anyway, it is this time of the year again; and there are some important deadlines and changes on the horizon. Free time is going to be a very limited resource in the next weeks, and after that I’ll listen to my itches again.

Are You a Social Learner?

If you read this blog, chances are that you contribute to Open Source one way or another. This paper is the most detailed study I found on the net about Open Source contributors like us and their motivation.

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.

Open Source Reference Manager

Sometimes I feel that Open Source has a critical dependency: the user. And sometimes I feel that users deserve the software they choose to use, and the conditions attached to it. Last week I had one of these days.

A customer asked me to solve a mysterious problem: Microsoft Word 2007 with Reference Manager 12 crashed, and then Reference Manager was completely unavailable, even after re-installing both. This university lab has been a good customer for four years now – server side. Client side, besides the one exception (who runs Windows in VirtualBox), they barely tried Firefox.

Scientist write. They write a lot and they cite a lot. They need a database of references, and they must format them to the specifications of the journal where they will be published. In this lab, Reference Manager is king. A proprietary solution, owned by information technology giant Thompson Reuters (who conveniently also owns “competitor” EndNote).

After a little bit of fiddling, and against every documentation I found on the web, I found that Microsoft Word has an aptly named registry key: Resiliency/DisabledItems. It has decided that it does not work with Reference Manager 12.0.1 and put it on a black list. Forever. The only solution was to delete the registry key!

Even in light of this obviously intentional bug that handicapped half the lab for two weeks (they tried internal IT before calling me): They still insist using Microsoft Office, because Reference Manager does not work with OpenOffice. And they insist using Reference Manager. Their principal fears are the lack of support and the loss of the database they have built over more than a decade. I was unable to articulate to them that their biggest risk is to have their data locked into a proprietary format.

I’ve searched the web and found a few open sourced reference managers. But I have no experience and also no time to evaluate a migration (unfortunately I could not justify a mandate). Are there any guides out there for users of proprietary Reference Manager to migrate to an open source reference manager? I’m interested to know, and I’ll keep that one on the back burner until the next opportunity to convince the customer to give it a try.

It seems to me that Open Source works best when users and developers are equally IT literate. When there is a too strong asymmetry between developers and users, the users tend to prefer the proprietary model in exchange for perceived support. It’s like with financial consulting: individuals will be happy to pay exorbitant commissions to their broker but will not pay a penny for the buy or sell advice, even if trading is a commodity and the real value added lies in the advice. Pay your Open Source developer and you will see dedicated, passionate support.

Repository Change Notifications on Sourceforge

Like many Open Source projects, Hugin and related tools are mostly hosted on Sourceforge. A pioneer open software incubator with a ten year history of community driven development, Sourceforge offers a wide array of tools at no cost for the developers.

We are very grateful to Sourceforge. Without its wonderful infrastructure, Hugin would not be what it is today.

The infrastructure has its quirks and sometimes feels slow / underpowered. Considering the circumstances, the Sourceforge team does magic to accommodate all the growth of hosted projects within the limited available resources. The site is victim of its own popularity and success amongst Open Source contributors and grows at a fast pace.

Bruno reported last week that Hugin was listed in Sourceforge’s top 25 active projects.

Sourceforge evolves at a steady, relentless pace. The team has managed to steer the course through the highs and lows of its corporate sponsor. They continuously look at improving the service to the Open Source communities hosted on their servers. We’re happy to have distributed version control systems available too, and they are currently looking into my request to have email notifications from Mercurial.

The Sourceforge team is progressive, open, and listens to those it services, even if it does not really get much in return (sorry, I wish we could give back more). They take feedback and ideas on their IdeaTorrent.

One thing that could improve in my opinion are mailing lists, specifically for notifications from Subversion or from the Bug Tracker. They are extremly useful to stay on top with the changes in the code. I recommend everybody interested in the progress of Hugin and related tool to subscribe and watch. Even if you are not a developer, you’ll find out what is going to happen. And if you are a newbie, you’ll get a unique opportunity to look over the shoulder of experienced developer and learn from the changes they make to the code. This was my main way to learn – patiently reading through each change, understand what it does, and slowly moving into its context.

I filed an idea for improvement there. I’ll shamelessly ask you to log on to your Sourceforge account and vote for it. Thank you.

Archimedes’ Principle

“Any object, wholly or partly immersed in a fluid, is buoyed up by a force equal to the weight of the fluid displaced by the object.”

Any change thrown into a community is rejected by a force proportional to the conservatism of the community and to the size of the change.

Change needs to be managed, particularly in Open Source communities.

1. Create a climate of less conservatism, e.g. by getting users used to small, non-critical changes (best practice example: Ubuntu’s continuous and small changes of skin between versions).
2. Float the ideas early and talk about them so that they won’t come unexpected.
3. Identify the key opinion- and decision-makers in the community and get them to buy into the ideas. Gather support.
4. Identify timing opportunities to introduce change (e.g. the new start of a development cycle is better than the middle).
5. Implement small chunks of change when the opportunity arise and when you’re sure that you have the available resources and support to make them fly.

I’m an agent of change. I just released Hugin-2009.2.0_beta2, and there’s more to come. Watch me. You don’t need to love me.

Give a Man a Fish

So the Hugin project team released 0.8.0 three weeks ago. What are the expectations, and what does release actually mean?

Some users, particularly in the Windows world, expect the release of a shrink-wrapped product. They expect to click, download, install, use. And of course everything for free.

Easy? Not so quick. What was actually released is nothing more than a tarball, an archive of the source code in a state known to build and work on the major supported platforms. So it could be used to produce executable binaries.

How are those binaries produced? What do they depend upon? What is to be produced? Who does it? How are they distributed? What is missing?

How

The user community has prepared platform-specific instructions. They may not be perfect but do the job.

Dependencies

There are some dependencies that need to be fulfilled for the recipes to work. Besides the obvious ones of enough disk space; a supported operating system; and installation of the building tools, Hugin 0.8.0 depends on other software packages, both at build time and at run time.

On the Ubuntu package description the dependencies are clearly listed. They are roughly the same for all platforms. They include enblend, enfuse, libpano.

What

On most Linux based systems a package manager takes care of the dependencies. This means that the packager only has to build Hugin-0.8.0 itself. The package manager will download and install the appropriate dependencies.

On OSX and Windows there is no package manager. The Hugin-0.8.0 binaries alone are useless. The packager has to do extra work.

Who

Anybody with access to a computer can act as a packager, use the instructions and the tarball to produce executable binaries and do whatever they want with it. It’s free.

Distribution

Anybody can put up the binaries for download anywhere on the internet. In the download section of this blog there are links. On top of that there are two distribution channels with special meaning: the package manager and the official Hugin download page.

The package manager is responsibility of the Linux distributors. They carefully test and approve each package that goes into their distribution. And they don’t backport often. For example, Ubuntu still supports its 8.04LTS distribution until April 2011 for desktops and April 2013 for servers, as well as 8.10, 9.04 and the upcoming 9.10. As of today, the binary of Hugin distributed by the package manager for Ubuntu 8.04LTS is Hugin-0.7.0_beta4. Users of Ubuntu 8.10 are still served with Hugin-0.7.0_beta5. Users of the most recent Ubuntu 9.04 have access to Hugin-0.7.0 binaries. And for the upcoming 9.10, Ubuntu’s plan seems to be to still ship Hugin-0.7.0. We hope that this will change but it is not up to us to change this.

Dependencies Revisited

Specifically, there are three dependencies that currently cause pain. In order of importance:

1. Enblend and enfuse are mandatory. Without them, Hugin-0.8.0 does not work. The current enblend and enfuse packages have serious problems, causing them to crash. They are a regression compared to previous CVS snapshots, in particular to those versions delivered with the old Windows SDK and with the Hugin-0.7.0 installer for Windows. There are fixes in the staging branch of enblend-enfuse. And Harry has been using that branch to build the OSX Hugin-0.8.0 bundle until his Mac died.
   Unfortunately the staging branch does not build in Windows yet. I researched the problem and fixed part of it (accepted as revision 347 by Christoph Spiel on August 3). Thomas Modes had a look at it before going to holiday and added some more pieces to the solution. But it does not build yet because of Microsoft’s Visual C++ quirks.
2. Libpano is mandatory. Until recently libpano had a minor but annoying problem: it reverted the language of the user interface to English. Daniel M. German and Thomas Modes solved it in the repository.
3. A control point generator is a critical. Until recently the autopano-SIFT-C package had serious problems, causing memory leaks and crashes; failing where the previous version bundled with the 0.7.0 OSX bundle and Windows installer succeeded.

On systems with package managers (i.e. Linux) the packager can simply publish Hugin-0.8.0 and rely on the package manager to solve the above listed issues. For systems without package manager the packager must add them to the bundle/installer or to the SDK used to build it.

Distribution Revisited

Distributing a binary that is known to have a regression over previous versions as official release is bad practice. It not only affects the project reputation, it ruins a working system for those users who overwrite the working version with the newer one.

The OSX Hugin users community fixed the problem and an official OSX binary is available from the Hugin site. There is no solution yet in sight for Windows, so currently Windows users are directed to the 0.7.0 installer. Maybe we should direct them to the tarball instead?

Conclusion

Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime. This works with most of our users ond most supported platforms.

Unfortunately for some Windows users it does not seem to work. Give them free fish and they will come for more. Give them the freedom to feed themselves and they will ignore it.