Virtualmin.com runs on a mildly customized version of an Open Source CMS called OpenACS 5.1.5, but it won’t be running on it for much longer. OpenACS is one of the oldest content management systems available. It is written in TCL and runs on top of AOLServer and PostgreSQL.
Some folks are already saying, “Ah! It’s written in TCL and you said the word AOL. No wonder you’re leaving OpenACS!” But that’s not why. I’m predominantly a perl developer working on a large existing codebase…I know that dropping a mountain of working code just to work in a more fashionable language is foolish. I also know that, despite its bad reputation, modern TCL is actually a pretty good scripting language. It’s not as pretty as Python or Ruby (but what is?) and not as powerful as Perl+CPAN (but what is?), but it’s a pretty good mix of features and clean syntax. TCL even has a few cool Lisp-y bits thrown in; which, as we all know, means that it is closer to god or something. More importantly, OpenACS seemingly provides a mountain of working code.
No, the reason I’m leaving OpenACS is because large portions of that existing mountain of code, despite claims to the contrary, don’t work. Worse, the aspects of the code that don’t work are not becoming fewer with each new revision, they are becoming more common and more difficult to fix. Working applications are being deprecated in favor of incomplete, bug-ridden, and poorly documented rewrites. What was once a pragmatic workhorse is now an academic playground. Unfortunately, I have only experienced the academic playground era of the project–but I’ll take everyone’s word for it that ACS was once a helluva stable and cool set of web applications.
So far, I’m just being bitchy, and not really doing much to point out the real and serious flaws in OpenACS.
An example is in order. The OpenACS Bug Tracker. It’s a nice bug tracker. You can see it in action at OpenACS Bugs. Have a look around. It’s slick. Very powerful, entirely useable, fast, searchable, all sorts of good things. I approve. So what’s the problem? What you see is not the code you get when you download and install OpenACS. In fact, it shares almost no code with the new bug tracker. How can that be, you wonder? Me, too. The OACS bug tracker was rewritten a year or two ago by Lars Pind, a smart fellow who thinks very deeply about web application problems. The problem is that Lars didn’t set out to work on the bug tracker. He set out to make a cool workflow package, and somewhere along the way decided that a bug tracker would be a great example application. Apparently, the rest of the OpenACS folks agreed, because when the bug tracker was rewritten to use Lars’ new workflow package, it replaced the original bug tracker.
The new bug tracker looks the same on the surface. It has no new features or bugfixes. As one might expect of all new code, the new bug tracker has some new bugs of its own. The most egregious being that it doesn’t allow discussion of bugs except between the site administrator and the creator of the bug. Think about that for a moment. How many times have you googled about a bug, found an entry in bugzilla or roundup or trac, and dropped in to leave your two cents. Maybe you’ve got a solution or a workaround to contribute. Maybe you just want to get on the CC list so you know what’s happening. Or you have an extra data point that might help the developer reproduce or isolate the problem. It’s an absolutely vital and core part of the modern bug tracker. And the new OACS bug tracker can’t do it.
“Big deal!” I hear you cry. I said so, too, when I was excited enough about OpenACS to ignore all of the problems and push forward with our deployment. “I’ll fix that this weekend. How tough can it be? Really, we’ll just drop a comment button on that sucker for other users and all is well. I bet it’s three lines of code and a template change.”
A year later the bug still exists. I spent a couple of whole weekends trying to fix it, and then after a couple of months of periodically trying to fix it myself, I filed a bug. One of the OpenACS developers has spent quite a bit of time trying to fix it. It’s been discussed in the OACS forums. It’s been discussed ad nauseum in a bug about the problem. I’m not a software development guru, and I’ll be the first to admit it, but this makes me very itchy. How can such a seemingly simple problem be seemingly impossible to solve? Probably, Lars Pind could drop in and fix it in an hour, but he’s not around on the OACS project any more…so it’s gotta be someone else, and no one else is available. In fact, no one else on the project even seems to realize that the bug tracker they’ve been using at OACS.org is completely different code from the one that’s being distributed with the OACS downloadable packages. It does seem that a few folks are using Lars’ workflow in other projects, so the expertise is probably there somewhere…they’re just not working on existing OACS code.
Which brings me to an interesting and confusing aspect of the OpenACS project. The developers on the project are universally very smart. They’re well-educated in software development, many of the them have years of of web application development experience, they keep on top of modern development techniques, and are aware of the competition. The codebase they started from (ACS) was, by all accounts, among the best in the industry. But somehow, the current state of the project can only be described as “a mess”.
The scary part is that I can’t really point to any obvious thing that the OACS folks are doing wrong. They are aware of many of the problems, and have excellent sounding plans for resolving them. In the beginning of my time with OACS, I thought I was seeing a rebirth of a once-great CMS. I accepted all of the minor quirks, because I could see the incredible potential of the system. It has a lot of great applications, already built. I’m a big fan of “already built”, when it comes to software development. I like to put together components, and I don’t like starting from scratch. What could be better than a project that has dozens or hundreds of supposedly well-written, and time-tested, applications?
But, it’s over a year later. The ecommerce application is still just a bunch of incomplete components that have to be heavily modified to be useful. Well documented applications like “Edit This Page” have been deprecated with no documented replacement…the documentation still covers using ETP, as though it works, when it hasn’t for several revisions. The tutorials for creating your own OACS applications result in non-functional code.
In short, OACS is a mess and has been for the entire time I’ve been using it, and it hasn’t improved remarkably in the areas that I use. So, I’m jumping ship. Rather than upgrade to 5.2.x on my production server, I’m going to use that time to write a migration script to move our users, forum posts, and bugs, from OpenACS to some other CMS. I don’ t know what that CMS will be, yet, but Joomla is certainly looking like a nice package from the hour or two I’ve spent playing with it (I’m going to reserve judgement until I’ve spent more time with it, since early enthusiasm is what got me into the OACS mess to start with).
I’ve spoken about the problems with OpenACS several times in the past year in the OACS forums, so if you’re interested in more of my bitch-n-moan sessions, this’ll keep you busy for a good half an hour or so:
http://openacs.org/forums/message-view?message_id=351756
http://openacs.org/forums/message-view?message_id=352267
http://openacs.org/forums/message-view?message_id=352288
http://openacs.org/forums/message-view?message_id=352505
Note that all of these posts are several months old, some nearly a year. All issues addressed still apply, as far as I can tell from a glance at my devel server (which is running the latest version of OACS). Which is why I’m moving off of OACS rather than spend more time/money/frustration on it. I’d use PHP before I’d touch another line of OpenACS code, and if that aint a damning proclamation, I don’t know what is.
Dossy Shiobara | 13-Oct-06 at 9:04 am | Permalink
Joe, thanks for putting these thoughts down so clearly. While I’ll let the OpenACS folks address your points towards them, I think the general AOLserver project (which I’m responsible for) carries very similar criticisms.
joe | 13-Oct-06 at 10:42 am | Permalink
Hey Dossy,
Thanks for your thoughts.
Actually I’ve enjoyed my time with AOLServer. You’ll note that I didn’t pick on it even a little bit. It really is a nice webserver, and all of the documentation, such as for building SSL support and the TCL binding stage, has been reasonably accurate. It’s not terribly flexible, compared to Apache, not fashionable (the word AOL almost makes it a fasionable anti-fashion statement), and a I had to install a few extra components from third parties to make it all work (SSL, and some other stuff I don’t remember), but it works well and hasn’t caused me any trouble in over a year of operation. There are some in the OACS community that view AOLServer as a serious liability, but I’m not one of them. While I concur that the way the OACS docs push oddball tools for every single purpose (e.g., djb tools, when pre-installed OS-standard tools are perfectly acceptable for the same tasks) is problematic from an adoption standpoint, having it’s own webserver isn’t even in the top ten reasons why I’m leaving OACS. If it were the only oddball tool involved, I’d consider it entirely a non-issue. The fact that oddball tools make up the whole recommended stack, except for the database, is an issue, especially when some of the competition (Joomla and Drupal) literally takes about two minutes to install. But now I’m back to bitching about OACS.
I’ll switch back to the subject of AOLServer, and say, “nice job”. And to answer your query on a thread you posted last month, a webserver with embedded JavaScript would be cool. A little oddball, but cool.
Dave Bauer | 13-Oct-06 at 3:58 pm | Permalink
Joe,
I can’t argue with you, you are right (except openacs.org is using OpenACS 5.2.3, including the workflow bugtracker, but that’s not really a big deal.)
The one thing you should notice is that OpenACS 5.3 is being released after we pass our automated tests, and there has been a big effort to improve quality. We have a long way to go, but I think the community effort so far has been outstanding.
Organizing a community around such a huge piece of software is a big problem, the documentation is a big problem. There’s alot of it, but you can’t be sure how up to date it is or if its right.
Install is another issue, and we have folks working on Debian packges, the rest of the OpenACS stack can run on official debian packages already (AOLserver, etc, without daemontools, but that is not necessarily required of course).
Thanks for taking the time to share this.
joe | 13-Oct-06 at 5:25 pm | Permalink
Hey Dave,
Thanks for chiming in.
I’ll note that the install wasn’t all that offensive to me–I installed it several times (laptop, desktop, and two instances on the production server) and it was never all that difficult. But I’m more UNIX nerd than web developer, and the majority of my job for the past 8 years has been packaging software. So that’s not proof of an easy install. As I mentioned in my comment to Dossy, two of the other CMS I’m considering switching to literally install in a couple of minutes (or 30 seconds, if you have Virtualmin Professional running…which, by golly!…I happen to have).
I do strongly suggest, as a parting word to the OACS community, that you lose all mention of Daemontools and the djb stuff from the docs. I ran OACS for a year and a half without them, and I certainly did not feel any pain from it–all of my problems were wholly unrelated to how I fired up the servers, served and received mail, or answered name service requests. It’s senseless complexity in an already complex process. (I’ve said it before, though, in the OACS forums…so I won’t go on more about that.)
I do believe the right things are being said and done in the OACS community, and the people are exceedingly smart. I miss the general aura of smart found in the OACS forums when reading the Joomla forums; some of those folks just aint firing on all cylinders, or perhaps they’ve never used a computer before that very moment when they posted. Those are the only two possible explanations I can think of for some of the questions and answers I see there.
I suppose the problems with OACS are just a matter of the fallout from the AD buyout and subsequent closure, Open Sourcing and porting to PostgreSQL, the coming and going of a lot of core developers, along with their individual vision of how things should be done, over a span of several years, etc. And, the fact that everyone has to first scratch their own itch, and that scratching has been focused on .LRN for a lot of the most serious developers. I don’t begrudge anyone scratching their own itch. After all, I’m leaving to go scratch my various itchy places, and I don’t feel a bit guilty about it. I just need to be working with a CMS where the needs of a sizable number of its developers and users more closely matches mine. I need ecommerce for software licenses, bug tracker, forums, in that order. Small set of needs, but they all have to work really well and be extendable with the skills I have handy (I don’t know any PHP but if the PHP developers I’ve know are any indicator, it aint exactly rocket surgery).
I sympathize with the conundrum you and the OACS folks are in, as I’ve worked on several large Open Source projects over the years (Squid, Webmin, SciPy, etc.). But we’re wrapping up our first year of software sales, and so I’ve got to figure out how to fix our software registration system to support renewals, provide nice license usage reports to users, handle expiries, as well as get several major unrelated issues with our current site resolved (sub-sites never worked right with some of the apps we’re using, for example). Every time I looked at doing it myself, or did the math on what it cost to have the initial simple software registration app produced and how much more work is needed to get the functionality our customers have been demanding, I just felt like I was digging myself further into a hole by sticking it out with OACS. And, of course, the bug tracker issue has been a thorn in my side from the first week. One of our very first users started the trend, and we’ve had regular complaints ever since. Seems small, but it seems bigger every time I look at it.
Not that I’m complaining. OACS has served me well (with a few caveats), the community has been grand, and I enjoyed tinkering with it, when things were going well. It’s sold a few hundred copies of our software for us, and helped us make our products better and our customers happier, and for that I’m grateful. If it could get us to the next level without cleaning out our bank account, I’d stick with it.
Obscene Art :: Choosing standard tools is next to godliness | 24-Oct-06 at 1:48 am | Permalink
[...] As I mentioned a couple of weeks ago, I’m migrating Virtualmin.com off of OpenACS, due to a number of limitations and bugs in the platform. After some consideration, research, and tinkering, it appears that Joomla is the best suited for what we’re doing with our site. It has good forums, a good FAQ manager, a decent bug tracker, and a good ecommerce package. All of them, except the bug tracker, look strikingly similar to the OpenACS applications they’ll be replacing…which is an odd, but nice, coincidence. [...]