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

individual-economic-advantage-free-software, posted by Andrew Cowie in /andrew/software at 17:16, 26 Oct 2006.

Tue, 24 Oct 2006

Conference Preparation

Speaker confidence

Probably the most important requirement to be an effective speaker is confidence. Confidence in yourself, confidence in your mastery of your subject, and confidence that you know that what you are saying (together with your slides, assuming you’re using some) are combining together sufficiently to convey the message you are trying to deliver.

One of the things that causes doubt while you are speaking is wondering if you are getting through to your audience. Often when you are trying to explain the intricate detailed technical aspects of something, you can’t help but wonder in the back of your mind whether you have explained enough context for your listeners to understand.

The catch, of course, is that you can’t get around this by explaining every last bit of background. There’s no time for that, and you’d lose the interest of your audience for sure. So you summarize, try to paint a picture, and hope that you have brought people along sufficiently for your main point to drive home.

I’ve started to wonder if we might be able to improve on this a bit.

Organizers’ concerns

Meanwhile, one of the (many) issues that the people running a conference go through in selecting presentations for the programme of their event is pondering the question of whether or not a proposed topic will be of interest to the audience.

Certainly once a speaker and their presentation are accepted, then the concern of the organizers is to ensure (ie, hope for the best) that each presentation will be not only of the highest quality, but of interest and benefit to those who attend. After all, there’s nothing worse than walking into a room and having no idea at all what the person speaking is talking about.

Speakers’ confidence and organizers’ confidence. It occurs to me that these issues are not unrelated.

Preparation?

At technical conferences, our audiences are our peers: highly intelligent, respected contributors in their own right. They might not be an expert in your particular thing (though you never know) — but they wouldn’t be listening to you if they weren’t interested.

So the question is, what can we do to help people who want to be better prepared so they get the most out of a presentation?

I used the term “homework” in as the zeroth step in a series of emails I recently wrote, but it was pointed out to me that for the conference context, homework has far too many connotations of “compulsory” to describe what I am trying to get at for improving one’s experience at a conference. So perhaps “preparation”?

In what form?

So here’s the question: what form should such an endeavour take?

Some have suggested to me that blog posts in advance of an event can seed the waters. That’s true, but even when an event has it’s own planet-type aggregator, there’s not necessarily a very high likelihood that the attendees to your talk will read your post. And in any case, blog posts aren’t generally of the detail and breadth that you probably want to be conveying as background material.

Another idea is handouts at the event. I’ve seen quite a number of business consultants do this, and it can be quite effective when it takes the form of speaking notes. There’s always the minor detail that if you give handouts that people will spend all their time head down reading them and not paying attention to what you’re saying. And there’s the logistical overhead of producing the damn things in the first place.

Traditional conferences (academic symposia, and the more established technical conferences like USENIX + SAGE’s renowned Large Installation System Administration conference and related Australian conferences) have long required full papers (perhaps with peer review, perhaps not) which are published in the conference “proceedings” and most of the time give to attendees when they show up, ie before they listen to the presentation. If they’re really diligent, they can read up ahead of time to figure out what the authors are on about and in so doing get more out of your presentation and ask you intelligent questions.

That’s all well and good for conferences who require written paper and which publish them in official proceedings, but not everyone does that these days, and more to the point, writing a formal paper represents an enormous level of effort. Certainly for more casual gatherings (ie, most open source conferences) it is prohibitive, and even for more featured events it still represents a barrier to participation. I don’t know about you, but in most cases, I’d rather be coding.

So what else? Many conferences have custom software they use to run their web site and and often you can browse by schedule, topic or speaker. That might be a good place to collect and publish background material, though it is ever a challenge to come up with a good web user interface for this sort of thing. If the conference had a Wiki (many do) that could work too, assuming it was organized sufficiently ahead of time — one page per presentation or presenter, perhaps. In either case, the catch is getting audience eyeballs to the material before the presentation.

What do you think?

Hm. Any other ideas?

Bear in mind that regardless of any ideas here, a presentation still has to be as vibrant, informative and interesting as possible for all attendees and that, in the end, no assumption of preparation can be made.

Nevertheless, I definitely plan to help people who want to get more out of the presentations I make in the future. It will help them, but even more importantly, it will improve my confidence, and hopefully that will improve everyone’s experience.

AfC

conference-preparation, posted by Andrew Cowie in /andrew/conferences at 12:21, 24 Oct 2006.

Fri, 20 Oct 2006

Learning about Java bytecode

There is a project out there called the Byte Code Engineering Library (BCEL), these days under the Apache Jakarta umbrella. It has been around for quite a long while and is both widely used and well regarded. They have a documentation page which has some surprisingly informative background material which caught my eye.

Long as I’ve been working with Java, I’ve never bothered much learning about the internals of the language that Java Virtual Machines interpret or of how class files are laid out. The overview in the BCEL manual of the .class file format and how Java VMs work on bytecode is excellent — far more informative than the introductory material in the more usual official references. In particular, section 2, describing the general design of the Java Virtual Machine, including a section on the Java class file format, bytecode instruction set will be a fascinating read for anyone interested in language design issues.

In case you’re wondering why this came up, I’ve been working on a design review for how we might go about re-engineering java-gnome, and have been doing one last analysis of the more outlandish outlying possibilities (ie unlikely to be chosen, but still worth a bit more investigation). Quite a number of problems would go away if we could do runtime class generation. It might be possible through BCEL.

As it happens I am extremely reluctant to follow this path largely because it’s a hell of a lot easier to express one’s ideas in Java and let a compiler generate the bytecode than attempting to muck about with bytecode oneself. Nevertheless, it may offer a possibility in terms of things like GObject properties which are largely only available via introspection at run time.

Naahhhh. :)

AfC

about-bytecode-bcel, posted by Andrew Cowie in /andrew/software/free-java at 14:09, 20 Oct 2006.

---

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

---