Operational Dynamics
Research and Development   |   Projects   |   Blogs   |   Source Code   |   Linux
October
Mon Tue Wed Thu Fri Sat Sun
           
26
         

hackergotchi
This section:

Blog postings by Operational Dynamics partners and staff

Use the links at top left for a consolidated feed of all the posts made on this site.

Please note the disclaimer at the bottom of this page.

RSS 2.0 Atom 0.3

Thu, 26 Oct 2006

Speculations about Economic Advantage as it relates to Open Source

I’ve been around the Free Software Open Source movement for long enough to know that the question that everyone wants answered is:

“How do I make money at open source”

When people ask this question they usually mean either “how can we be a software house that releases its code yet still makes revenue” or “how can I get a job for a company that lets me do whatever I want, ie work on FOSS”.

When Danese Cooper talks about this, she adds an interesting view point: reducing cost is also making money. This isn’t of course what an individual or entrepreneur means by making money, but it does serve to underlie much of the collaboration you see between companies and is often the justification used internally to explain why they are using (and more to the point, have people working on) Open Source software.

Defenders of the FOSS movement cite reduced costs, better quality, and immense social benefit. Even though I consider myself an Open Source person (tolerating non-free), I believe that Software Freedom is a defining characteristic of the information age and cannot help but be a driving force if we are to continue to raise the global human condition. It’s a privilege to be a part of it all.

That doesn’t change the fact that the question posed above was a legitimate one: how does one derive sufficient economic advantage to be able to do so? Though I’ve long pondered the financial side of Open Source, and often pontificated about it, for the first time I’ve run smack into the question as a protagonist, not just a commentator. And so I have a little story to tell.

An exceedingly elusive bug

I am the maintainer presently of something called the java-gnome project, which is a set of language bindings allowing you to write native GTK and GNOME programs in Java. I certainly didn’t write the existing code, but rather inherited a project that is well over 8 years old and has had many teams of maintainers. They’ve all moved on, however, and now I reluctantly have the job because the previous guy just up and vanished about a week after I got cvs commit privileges. [Open Source. Gotta love it :)] Since then, both because we use java-gnome extensively for our in-house work, and because of the process of working through bugs and patches and releases, I have developed a reasonable level of experience with the codebase. (It’s actually an awful mess in there, which is why I’ve embarked on a major re-engineering the damn thing — but that’s a story for another day.)

Meanwhile, a certain Company X has been making tremendous strides in an enormous application which happens to use java-gnome. They made quite a few valuable contributions, especially early on, but now have adopted the attitude that “it’s good enough for our purposes”. They seem to want the project to keep ticking along, however. As they have developed quite a dependency on it, I have pointed out on a few occasions both in-person and online that it would be astute of them to engage our firm for support and/or as a means of sponsoring further development. They have thus far chosen not to act on this, which is their choice, of course.

They’ve since run into a rather nasty bug. It crashes their application. They have since been messing around for over 58 days getting quite irate about it, but unfortunately it was something that no one else ran into. What a predicament.

Because Company X is itself a major Open Source vendor with links to the earliest roots of the Free Software movement, their engineers very much have a “we can fix [anything] ourselves” attitude. Thus mentioning that this might be a good occasion to find a way to do business together didn’t really go anywhere. Even so, I did look closely at their original bug report, discussed it extensively with their staff, did a fair bit of digging, and made some suggestions. Regrettably that didn’t resolve the issue, but it seemed like they were on the right track.

As I had already invested a good day of time in trying to help them out pro bono as a good faith gesture in my capacity as titular maintainer of the project, and because of their reticence to engage us in an appropriate business conversation, I have since been patiently observing. After all if they fix it for themselves and contribute that fix then that is a perfectly good Open Source outcome. I actually rather expected that they would nail it quickly, but somewhat surprisingly, no solution presented itself, and their occasional discussions of on IRC and in the bug report itself certainly gave the impression that they were up against a devilishly difficult problem exceedingly difficult to trace debug.

It took until yesterday for someone to achieve a reproducible test case. That of course is a terrific achievement for any bug [although in this case, the test case turns out to be a code snippet they posted a month ago but hadn’t put into the form of a simple program, which is a shame. Might have made progress sooner. Or maybe not].

I didn’t want to really get into it for someone who has not yet decided to engage us and/or fund the project, but being a good sort I did say I would have a brief look if they generated a test case. So I took half an hour this afternoon to run the new code and see if I could duplicate the crash. I could. Yeay!

This evening I looked at it again for a moment, then traced the calls through, and then started experimenting with EXACTLY the course of action I recommended 45 days ago. I assumed I was probably wasting my time, as I was pretty sure they’d exhausted the possibilities there, but I figured I should start at the beginning. Anyway, after experimenting with various refactorings of the test case to ensure the isolation was accurate (it wasn’t, but at least it reproduced the crash, though not when they thought it did) I tried looking at what I suggested 45 days ago and fixed the bug in about 30 seconds.

So now what do I do?

AJ’s market hypothesis:

I have had great interest in the discussions by Anthony Towns and others about AJ’s markets. His conjectures have much been on my mind of late. He notes that the key economic driver is that once code is released, its value effectively drops to zero. From a mechanism standpoint, one therefore MUST be in a situation where you charge fees in advance (which, while normal practice for any management consultancy and certainly our policy, is somewhat unusual for the software industry). A tempting alternative would be escrow, but if GPL software is involved, then the act of giving a copy of the code to an third party for verification would, by the terms of the licence, nullify your protections because they can of course do what they want once they’ve got the code — like giving it to your client!

So as for the question of the fix I may have found, I could just give it to Company X (ie, fix the bug and commit the code) but given the entity’s behaviour and reticence regarding my suggestion that they had passed beyond the point of simple and reasonable co-operation for the greater good and into consuming a professional service, I am not especially inclined to just give it to them free. From a negotiating standpoint, that would seem to equate to giving in (ie, they got what they wanted without paying for it). But it’s not like I’m selling something. I’ve already invested the time to find a fix. The question is monetizing that time, and the person-years of effort it took to reach the level of expertise necessary to be able to do so.

I have actually been quite surprised at the attitude I’ve been getting from some of them — as if I owed them something. We all know how that is [people demanding things of others in the free software movement] and we’re all guilty of it, but I was a touch surprised that such an experienced crew of open source hackers would act so. But upon reflection I realized I was off base, and that the real problem was something else. It’s something I run into quite frequently in my business: techies are not business people. They are used to working with each other in environments where the economics of people’s involvement has already been resolved — ie, “we’re from EDS and we’re here because your government department outsourced to EDS. We’re employed and you’re employed and neither of us are doing business together — we’re working together because we were told to.”

So in this case, collaborating with a crew of people who work for a large Open Source company, they’re all already paid hackers and wonderful people used to giving their heart and soul. I, however, work for a company that needs business in order to pay its employees. Drawing inspiration from the kind of gigs that Imendio and Fluendo have going, we have taken the entrepreneurial risk to develop expertise in something in the hopes that, even if it did not become a major business activity, it would at least generate some offsetting revenue to cover some costs. But so far no bite from Company X. And although there are Company Y and Company Z that I also hope will choose [to] support, this is a bit of a case study and demonstrator; the others are longer shots.

While we were discussing this tonight in #slug, James Purser suggested to me:

It is the eternal question I guess, weighing up community good vs the need to eat

In my view, the question of common good is only pertinent once the economic issue (for the individuals involved, at least) has been removed. Once it has been, then all concerned can work towards optimizing what is the best for both them as individuals (ie, The Hacker Ethic — the satisfaction of doing work you want to do well) plus what is best for the company they represent (ie, reducing costs arguments that go along with joint ventures, the pursuit of efficiency, and competitive advantage).

No; the interesting question is leverage, as relates to the AJ markets notion. The playing field is not level because of the individual economic issue. The value of released code is zero, but the idea of withholding a bug fix is so anathema to the entire underpinning of the Software Libre movement that I recoil from it in horror. I don’t want to be an ogre, and risk being branded so by even discussing the issue. It’s an interesting dilemma.

AfC


RSS 2.0 Atom 0.3 Category Specific Feeds. Use these links for an RSS or ATOM feed limited to this category and its descendants. Technorati Profile


Material on this site copyright © 2005-2008 Operational Dynamics Consulting Pty Ltd, unless otherwise noted. All rights reserved. Not for redistribution or attribution without permission in writing.

We make this service available to our staff in order to promote the discourse of ideas especially as relates to the development of Open Source worldwide. Blog entries on this site, however, are the musings of the authors as individuals and do not represent the views of Operational Dynamics. All times UTC.