WPI Presentation

In early April I gave a talk at the WPI Computer Science Colloquium.You can find a copy of the presentation here. In the coming weeks I'll discuss a number of topics from that presentation on this blog.

EclipseCon Presentation

I'd like to thank everyone who attended my presentation yesterday, and for the interesting discussions that followed. As promised, here is a link to the presentation.

Images of Open Source

I'm reading Images of Projects by Mark Winter and Tony Szczepanek. The premise of this book is that projects can be viewed from a number of different perspectives, and the perspective we choose (at a given moment) will influence how we think about the project and other important factors, such as how we make decisions, what is viewed as important, and so on. This book follows the tradition of Gareth Morgan's influential Images of Organization, and certainly brings a much needed higher-level view of the complexities inherent in projects.

These books made me think about images of open source. Off the top of my head I came up with the following:

• Ideology: The part that emphasizes "free as in freedom," copyleft, and so on.


• Life style: Related to the Ideology image, but more concentrating on Do It Yourself (DIY) and similar movements.


• Business Model: Seeing open source as a way of running a business.


• Marketing Gimmick: Related to the Business Model image, but seeing open source as a marketing tactic to increase visibility, etc.


• Social Movement: Emphasizes the community aspects of open source, especially around virtual, highly-distributed, ad hoc community dynamics.


• Mean of Production: Sees open source as one way of producing and managing goods (or knowledge). This is the image where most of my research centers.

This isn't meant to say that these images are exclusive: clearly some images overlap, but I hope that each highlights an important aspect and enables the dynamics that are discussed in the two Images books mentioned above. Also, this list likely needs refinement, so any suggestions would be appreciated. :)

The business of open source, again

Preparing for EclipseCon, I had a chance to browse my past presentations. At EclipseCon 2007 I presented The Garden & the Market: The Value of Eclipse Open Source. This is probably my favorite presentation, and I think there still is a lot to say.

When I gave that presentation in 2007, I was working at a company where open source was a minor means of software creation. Since then I joined Red Hat and now open source is the means of creating software. The whole question of building a business based on open source suddenly becomes more pressing. :)

One aspect I really liked about that presentation was the audience participation. We genuinely had a conversation, one which in several cases lasted longer than the actual presentation itself. I'd like to loop back with the Eclipse community this year, and see how things look three years on. When I arrive at EclipseCon, I'll seek to secure a BoF slot for this purpose, and I look forward to the conversation. If anyone would like to meet separately, please drop me a comment here (or to the email in my profile), and we'll try to meet.

On purpose, an emergency

The frantic pounding on your door jolts you awake, and noticing that it is three in the morning doesn't calm your nerves. You peek out the window, not really knowing what to expect, but any speculation is immediately cut off by the fire you see climbing up the side of your house. Before you can react, a man appears (the one who was pounding on the door, you guess: funny how the mind can still reason so quickly under such stress), takes your garden hose and begins to spray water onto the fire. By the time you stumble out the front door, the fire is almost out. Panting, you stumble up to him and stare at the scorched wall. “I was on my way home from work,” he says, “and I saw the fire. Lucky I put it out before it spread.” You thank him for helping, and offer a reward. He turns down the offer, saying he was just glad to help.

Of course you would be grateful to someone who saved your home from a fire. But how would you feel if you later learned that he had also set the fire? What kind of lunatic would do that? Certainly you would not feel like offering a reward under those circumstances.

Yet we routinely praise and reward people who do the same type of thing in software business. A sales person runs into trouble with a customer, waits until the customer is really upset (due to inaction), and then “helps” to solve the problem by short-circuiting company procedures to “do the right thing for the customer.” A software team waits until late in the project to announce that certain serious problems – which they had known about for a long while – are going to cause a schedule slip. The team then makes a heroic effort to finish, and is thanked afterward for “getting it done.” We are happy when a vendor fixes a problem in their software, after much complaining and arguing from our side, even though all the vendor did was fix a problem it created. Whether through ignorance, incompetence, lack of planning or gamesmanship (it is easier to force an issue with a preferred solution if time to consider the problem is artificially cut), we are are grateful that the problem was solved and that the team “pulled together” at the crucial point. We breath a sigh of relief and move on, waiting for the next fire.

But we fail badly each and every time we move on with first looking back. We fail to ask the key question: How did the emergency arise in the first place? In the heat of the emergency, such questions are usually cut off with well-intentioned statements like “this is not the time to point fingers” (many times by those who created the emergency, for obvious reasons). Although that is probably right (during the emergency you need to react to address the challenge), it does not mean that you shouldn't ask in retrospect. You have lost a chance to learn and avoid future emergencies for the same reasons, and you have set the stage to reinforce the bad behavior that relies on such emergencies to get things done.

Spoon, fork or knife?

Administrative note: thanks for all the comments on my previous post! I haven't found a solution, but have moved on to the “latest and greatest,” which has circumvented the issue. For those interested in the “question overhead” discussion take a look at BZ241335, comments 7 and 8.

OK, so I'll try one of these metaphorical postings. Be kind and work with me here, I'm no Ed Merks for writing these, after all!

How do you consume your open source? Spoon, fork or knife? It's nice if you can use a spoon; take it as is, slurp it up whole. Even nicer if someone spoon feeds you. What if you don't exactly like the taste? Maybe add some seasoning, or prevail on the chef to alter the recipe. Perhaps suggest variations to the chef, or even help the chef cook (assuming the chef wants you mucking around in the kitchen the insurance policy allows it).

You could also consume it with a fork. This gives you more control to pick and choose the next bite, but also brings the substantial responsibility of not sticking your fork into more than you can swallow. Poor use of the fork is a primary cause of choking, and it's not pretty to watch or hear. Of course, if you are skillful with the fork and can take just the right amount, you get to eat as you wish.

Then there's the knife. You're given a meal, but clearly can't consume it whole (unless you're a creature with one of those magical expanding jaws and a big enough mouth). Also, there might be parts of the meal you don't like, and want to avoid through judicious use of the knife. So you carve the meal and take it as you want, when you want. It's extra work – wouldn't it be nice if the chef carved it for you, so you could just use the spoon – but worthwhile to get the bites you want.

But probably you're like most people: you use the spoon, fork and knife in some combination that seems to make sense for the meal. The spoon is fastest, and the others require more work. Sometimes you might carve with the knife and use it in a stab to consume the separated piece (which is dangerous, by the way. I hear that people long ago were more skillful with the knife and actually ate like this). Or maybe you are like me: you tend to use the fork to both carve and stab (a habit, which I am told, betrays my lack of a proper upbringing).

In the past I've mostly consumed Eclipse meals using a spoon, with (rare) occasions for the knife to make bites suitable for the spoon. Over time, I find myself using the knife more and more, and the fork seems to have a renewed purpose. How about you?

Walking away from bugs

One of the most frustrating things that can happen to an open source committer is to meet someone who tried your software, ran into some problem, and just walked away. Did you check the error log? Did you ask on the newsgroup/mailing list/forum? Did you file a bug? As a committer, these questions roll off your tongue. After all, open source is a collaborative effort, and success depends in large part to the collective effort of the community. Walking away like that is just not good citizenship!

Or is it?

Recently I needed to evaluate some plug-in code that was written on a Ganymede-based target platform. For reasons not important here, my development environment is based on Europa at the moment. Eclipse has great support for these cases, however, and setting up various target platforms is routine for me. So, I go and set up the necessary target platform, load the evaluation code into my workspace, and set up a launch configuration. Right – so let's run these plug-ins and see how they work. The splash screen appears and shortly after – bang! It dies with an error* Strange. I've been developing open and closed source plug-ins for Eclipse since V1, and have dealt with all sorts of platform configurations and error conditions: never saw this one before... Mess around with the launch configuration, read config.ini (like the error message suggests); nothing helps. Ok – off to an internet and Bugzilla search for the issue: clearly I must be doing something stupid, because Europa should be able to launch Ganymede-based target platforms (right?). Hmmm... some discussion about this type of error, but nothing seems to fit my case. Try launching the target platform directly, and it works fine. A few more minutes of searching, a few more minutes of messing around with settings. Finally, I walked away.

And then I thought about it. Why did I walk away, and what does that tell me about open source users who do the same? Well, in my case, and I suspect this is common, the reason was pretty simple: my task at hand was to evaluate the plug-in code, not to debug an Eclipse launch failure. I was trying to use Eclipse to work on another problem, not on Eclipse itself. I could get the information I needed in another fashion, and that's what I did. Now, being an open source committer, I felt a little guilty: surely I'm not walking away, but rather I'll get back to that problem. I'll do The Right Thing and check all possible avenues: I'll read everything I can about it on the net, I'll ask on the newsgroup, I'll file a bug and follow up. Yes, yes I will! I will get back to it, right after I get these other things (that I'm paid for) done... Then again, maybe not (to be realistic).

I even felt guilty about writing this blog entry. Who I am to complain when I haven't done my homework? But then I realized that something larger was interesting: my attitude toward the whole situation. Maybe a kind reader will point out an answer for my problem, one which will probably seem entirely obvious, if I had looked in the right place. If so, thanks! But fixing this specific issue is really not the point. Maybe you'll flame me: You don't understand how open source works, you've got to engage the community! To this I'll answer: You don't understand your users! How many of them have walked away silently?

When I was in graduate school, a friend of mine was doing his Ph.D. In the physics department at MIT. Maybe it's a measure of what it takes to operate at that elite level, but he once told me (without pride or arrogance, but simply matter of fact) that he was never shy about asking a question in class, because if he didn't understand something, it was the professor's fault for not being clear.

Just to be clear (because I don't mind being flamed, but prefer to be flamed for what I actually meant): I'm not blaming the Eclipse platform or any other Eclipse project/committer for the error I encountered or my inability to fix it quickly. Rather I am just pointing out the observation that I feel compelled to do a lot of work before raising an issue, and I wonder if this “barrier to the question” is the reason why people walk away. If so, what can be done?

*java.lang.IllegalStateException: Unable to acquire application service. Ensure that the org.eclipse.core.runtime bundle is resolved and started (see config.ini).