John Reynolds's Blog

Open Source Archives

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

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".

Learn by Teaching: Examples using the Tapestry Table component

There's an old saying that the best way to learn something is to teach it.

I've been evaluating the Tapestry Web Component Framework for a new project, and I really needed to learn how to use Tapestry's multi-page sortable table.

What better way then to create an example application to share with others what I have learned?

If you've got an itch to learn a bit about how to use Tapestry's Table component, please download TapestryTables.war and try it out. I have tested this application with Tomcat 5.0, but I think it should work with any standard servlet container.

I've been exposed to Tapestry before, and I am quite fond of it, but I had never used the Table component. This particular component is very powerful and very flexible... good attributes when you need to use the component, but sometimes a source of confusion when you're first learning how to use it.

Tapestry is well documented, and examples for using the Table component are included in the distribution, but at first I couldn't quite figure out how to do what I wanted.

Happily, after a bit of judicious lurking on the Tapestry Users List I was able to figure out how to do what I needed to do.

There are some really helpful people out on this list, and I'd like to single out Jamie Orchard-Hays in particular. His patient responses in a series of exchanges with Lindsay Steele really set me on the right track.

I am delighted with the movement towards Web Component Frameworks for developing browser-based applications. With Tapestry, Echo, and now JSF it won't be long before the days of tedious JSP tags, JavaScript libraries and custom handlers pass into the mists of memories.

A critical element necessary for these open source frameworks to really take off is the wide availability of examples for the various components. A lot of really talented folks have developed some great components, but they sometimes need help in documenting and demonstrating their creations.

If you do have a chance to check out my examples, please let me know how I can improve them, and by all means feel free to pass them on and expand them. Hopefully, TapestryTables.war is just the first installment in a series.

Update: Oct. 6th, 2004 - I've updated TapestryTables.war to incorporate suggestions and add some examples of Editable tables.

Continue Reading...

This work is licensed under a Creative Commons License.