Open software pragmatism - Free (as in beer) isn't the point

Back in the mid-90's I was working on the user interface for a Windows desktop application that included a fairly sophisticated cross between a table and a tree component. We wanted to display a multi-column table of assets where each row was actually a summary of information; for example one column was the total value of the asset. Each row of the table could be "expanded" to list the details of all the transactions that were "rolled up" into the summary. You see similar components all over the place today.

Fortunately, even in the 90's we did not have to write this component from scratch. A commercial table/tree component was available (for a reasonable price), and we were able to purchase a source-code version that allowed us to modify the code to our hearts content. One huge advantage to having the source code of the table/tree component was our abilitiy to debug problems, and if the problem turned out to be in the table/tree component itself, we could actually fix the bug instead of having to work-around it.

The downside to having the source code came whenever an updated version of the table/tree was released. If there was a feature in the new version that we wanted to use, we'd have to reapply all of the enhancements that we'd made to the previouse version, and more annoyingly we would have to figure out if the bugs that we'd found in the older versions had been fixed (if not, we'd have to hope that our old fixes could be applied to the newer code base).

As I mentioned before, this was in the mid-90's. The Free Software Foundation was alive and well, but very focused on Gnu's Not Unix. I was working in the Wonderful World of Windows, where Open Source was yet to gain a foothold, and everything cost money: You paid for development tools, you paid for libraries and components, and you certainly paid for source code. Perhaps because of my youth and enthusiasm, paying for stuff didn't bother me very much. I remember that I would often buy a development tool*** that I wanted to use ... usually from Borland because they had great tools for a reasonable price... and then talk my boss into letting me use these tools at work. If I was lucky, I would get reimbursed, but that didn't very happen often, and I usually didn't mind. (*** Note that free development tools such as the Gnu C++ compiler and Emacs were available on Window at the time, but they just didn't have the polish of the tools that you paid for)

Paying For Stuff wasn't annoying; Persistently Unfixed Bugs were annoying. I remember being really pissed with the vendor of the commercial table/tree component because there was not an effective process for submitting bug fixes to the vendor (It was understandable that a reported bug might not make it into the next release... but not when you had sent them the fix). My colleagues and I became very intimate with the internal details of this component, because we were stressing its functionality a bit farther than it could go... and we often found (and fixed) bugs in the component long before the vendor knew they existed. Applying these patches over and over again to subsequent releases of the code base really "chapped my hide".

Life here in the 21st Century has certainly changed with respect to Paying For Stuff, especially with respect to source code. I've done no real survey, but I would be willing to bet that the source code for most of the frameworks, libraries and components that developers rely on today are readily available. We simply don't tolerate hidden code anymore: If I can't see your code, I'll use somebody else's code that I can see (whether or not I have any intention at all of actually looking at the code).

As the last bastions of "closed code" fall, such as Sun ovecoming its earlier reluctance to "Open Source" Java, I want to shout out a reminder:

Free (as in beer) isn't the point

Of course that is an overstatement: We never liked paying more for something than it was worth, and we always liked getting a bargain. I'm just saying that for most of us money was never the biggest issue. The biggest issue was (and still is) Persistent Unfixed Bugs, and the second biggest issue was The Right Interfaces To Build On.

Go back with me to the mid-90's and revisit the issues that we had with that table/tree code that we'd purchased: We were pissed that bugs that we had fixed ourselves never made it back into the official code base, and that we'd sometimes have to significantly mangle the code to add in our own enhancements. If there had been an effective process for getting bug fixes back into the code base, and if there had been an effective process for refactoring the code base to enable end-user enhancements, we'd have been tickled pink.

The same is true today. Allow us to get our fixes back into the code base, and pay attention to our requests for refactoring and API changes, or it's not going to make much difference that the code is now "Open Source".

(cross-posted at my java.net blog)