In case you couldn't quite place it, I stole the title of this article from one of my very favorite singers of all time, Janis Joplin. And if you did recognize the song, did you know that it was written by Kris Kristofferson? And that, dear reader, takes care of the obligatory history lesson.
The lyric itself is dead on point to today's discussion, though. Especially hearing Janis' incredible raspy vocals, I really get the idea that the singer of the song has a completely different vision of freedom, a different sense of what most of us think it means to be "free." In her mind, it's not about acquiring enough possessions or amassing wealth, but just the opposite: Freedom is being totally, completely unencumbered by anything material—a very '60s beat concept.
So Just How Free Is Free?
So now fast forward about 40 years and we have a new situation in which we need to define what "free" means (and no, this isn't a setup for a Clinton gag). There's actually a really good line going around the Internet these days. I've seen it as an email tagline and in other places as well: "It's not the software that's free, it's you." And that's the point I want to address today.
Recently, I decided to start delving more heavily into the world of open-source software. It was the inevitable result of my own current experimentation with JavaServer Faces via IBM's EGL language, my initial encounters with Python through the Zope/Plone content management system (CMS), the recent announcement of a "native" port of PHP for the iSeries, and finally the highly visible grass roots movement surrounding Ruby and especially Ruby on Rails. In order to understand this brave new world, I needed to really get my hands dirty.
The Project
Well, the first opportunity to take a shot at this presented itself as the result of a confluence of several events. First, I needed to write an article about open-source CMS systems. Second, I wanted a Web-enabled tool to help manage a current project, and the idea of a wiki looked like a good fit.
In a previous article about installing an open-source CMS system, I remarked that the installation went reasonably well despite the fact that I had to hack the code a little bit. I also implied that my ability to do the hacks was attributable to the time spent coding in Java and that I'd probably not do nearly so well in other languages.
Well, let me tell you about Trac. Trac is a combination wiki and issue tracking system, the perfect thing to help organize the issues that come up in the course of a normal development project. The wiki portion of the tool allows you to define terminology, organize design thoughts, and share ideas about architectures, while the issue tracking part is perfect for defining specific individual tasks, assigning them, and tracking their progress. Together, these can provide some real help in managing a project, particularly one that has high time pressures and requires lots of triage; even lower priority ideas can be recorded in the wiki, and for hot items, tickets can be added to the tracking system that point directly to the wiki entry for that particular feature (and vice versa). And it's all free! Sounds too good to be true, doesn't it?
What Happened?
I'm glad you asked, because the answer is that you really do get what you pay for. Let me just recount the issues. First, I had to identify what all to download. And while the Trac Web site has some good installation documentation, there are things that just don't happen magically.
First example, I downloaded Apache. I got the latest and greatest version, Version 2.2, and I installed it. Next I wanted to go get Python. Python has two basic modes (as do many Apache plug-ins): standard CGI calls to the Python interpreter, and the mod_python Apache HTTP Server module that integrates directly into Apache and provides much better performance ("much better" being code in the CGI world for "acceptable" and usually what is required for production-level work). I of course wanted the better-performing option, which led directly to open-source roadblock number one. The mod_python module is incompatible with Apache Version 2.2. So I had to go back to the Apache site and download Version 2.0.59. Watch the daring systems integrator as he performs his balancing act on the high wire! Will he go for the features of the newer version of Apache or the superior performance of mod_python? And how in the world does he decide? In fact, how did he even figure out what mod_python was, anyway?
Research, that's how. Which translates to time. Time spent on the Internet. Time spent reading documentation. Time spent scouring newsgroups. Time spent trying various combinations to see what works. And that was just two of the modules!
It gets more fun. Python, like most interpreted languages, talks to the world with special hard-coded "bindings," which are typically platform-specific modules used to call other applications. Trac wants to use Subversion for version control. Unfortunately, in order to be compatible with Version 2.0 of Apache, the Subversion bindings for Python need to be compiled with Microsoft Visual C++ Version 6, which is not compatible with the later version of the Microsoft compiler used to compile Python Version 2.4. So the later version of Python that I installed wouldn't work with the Subversion bindings. Oh joy.
There was a fix, though. After spending many hours just to figure out what the problem was, I then spent a lot more hours researching the fix, which was this: download the Subversion bindings for Python 2.3 and then, with a hex editor, go in and modify the half-dozen or so DLLs that are part of the Subversion package, changing each instance of Python23.dll to Python24.dll.
Was It Worth It?
Boy, I guess that really depends on what you mean by "worth it." For me, I was happy to get the wiki up and running; it's already seeing lots of use. I may eventually move to a different wiki product; there are lots of them out there. But this one will also provide me with the ability to earn my Python chops. So for me, yeah, it was probably worth it.
But if my goal were to find an enterprise-ready, mission-critical solution, I'd have to say this fails on a couple of counts, from fragility to the sheer bulk of minutiae that I had to learn just to get this far. I don't know how many people have the time to chase down instructions for hex editing DLL files and even then how many would install the patched programs into production.
So in the end, you do indeed get what you pay for, and in the case of whether a given open-source package will work for you, just remember to budget time—more time than you would spend on a typical System i tool.
Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSc: Step by Step. You can reach him at
LATEST COMMENTS
MC Press Online