• Subscribe

    Subscribe to This Week In Panospace by eMail.
    Subscribe in a reader
  • License

    Creative Commons License
    This work is © 2008-2012
    by Yuval Levy
    and licensed under a
    Creative Commons License.
  • Entries

    October 2014
    M T W T F S S
    « Dec    
     12345
    6789101112
    13141516171819
    20212223242526
    2728293031  
  • Archives

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

4strokesEver 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.

01-ms_office_ribbon

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!

03-win_registry_hack

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.