LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Open-Source Context


By Allen Holub
January 15, 2005 — 
I’m conflicted about open-source software. I just read yet another alarmist SCO-versus-all-that-is-good-with-theworld magazine article that fretted that the SCO-IBM lawsuit meant the end of open-source software. As I read, I found myself thinking that, even though I use a lot of open-source stuff, the end of open source as we know it might not be such a bad thing.

My most recent experiences with Tomcat demonstrate my dilemma. The newest version of Tomcat was just plain broken. It didn’t load and run custom tags correctly, for example. Though I could (in fact did) go to an earlier version, the fact that Tomcat wasn’t subjected to even rudimentary regression testing is disturbing.

The next issue is one of documentation and developer attitude. I wanted to use a local-configuration-file mechanism that’s pushed heavily in the documentation (context.xml), and I was deploying from the development directory using the Ant build.xml file that’s shipped with Tomcat. This process simply doesn’t work.

I started with the documentation to find a solution. Tomcat’s documentation is virtually unusable, though. It’s a hodgepodge of inadequate .html files. There’s no way to print it. There’s no real organizational principle, index or search mechanism. A lot of the documentation is written by developers for other developers, so it is sketchy at best, and incomprehensible to a new user.

I then subscribed, reluctantly, to the Tomcat-user mailing list. I say “reluctantly” because this is a high-volume list with a lot of noise on it. The answer I got from the list was disturbing. I was told that direct deployment from a development directory was added only because users demanded it.

The developers (I’m reading between the lines) didn’t really want to add the feature. They also didn’t want you to deploy from a directory for philosophical reasons. Consequently, they implemented local-directory deployment badly—in a minimal way. A casualty of this process was context.xml. In order to get that feature to work, I would have to deploy in a jar file. However, jar deployment is a real annoyance when you’re doing test-driven development because it adds time to the very short (5-minute) compile-deploy-test cycle.

Moreover, nowhere do the docs even hint that context.xml works only in a jar deployment.

The most disturbing part of this discovery process, though, was the attitude of the developers who were contributing to the list. The prevailing attitude was one of arrogance, elitism and general contempt for the poor slobs like me. I admit that I’m easily annoyed by developers whose sense of self-worth seems grounded in knowing more than anybody else. Inadequate documentation is a side effect of this attitude, since gurus lose their guru status if they commit their knowledge to paper. Most of the problems discussed on the list should have been addressed in the documentation.

So I checked out the source code, thinking that I might be able to add a patch myself. Not surprisingly, the code is a mess. It’s poorly structured, poorly documented and poorly written. Poor code quality in an open-source project shouldn’t be surprising. The code is, after all, put together by people with time on their hands.

Some other open-source source code that I’ve seen is equally bad—Hibernate is a mess, for example—and many commercial projects aren’t much better (much of the Java library code is a case in point). That is, badly done code isn’t in and of itself a reason not to use a piece of software. Combine badly done code with inadequate testing and documentation, however, and you have the makings of a disaster.

The bottom line is that you have to do a lot of work to use an open-source product like Tomcat. You have to test new versions rigorously; you have to compensate for inadequate documentation by using a high-volume mailing list that may or may not provide an answer in a day or two; you have to trust amateurish code, which you can’t really repair yourself because your version will no longer be “standard.” Even if you could repair the code, progress on your real project would slow down.

All of these problems translate directly to wasted time and wasted money. The Tomcat team has no incentive to fix any of this because they’re not being paid and have no market pressure on them to improve quality or provide real customer support. I know that the open-source party line is that third parties will step up to fill these gaps, but then you’re paying for the software, aren’t you? So much for the price advantage.

In all fairness, some open-source projects don’t have many of these problems, but those projects tend to have started life as commercial software that was released to the open-source community. I have to believe that the same market pressure that pushes a commercial product can’t help but forge a better product. z

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.


Share this link: http://www.sdtimes.com/link/28336
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading