Forum OpenACS Q&A: Re: Reuse in the large is an unsolved problem !?
My feeling about OpenACS is that it has become relevant only to .LRN. It is becoming more and more a marginal development platform. That doesn't take away from its technical strengths. Its primary weakness is the lack of innovation. SOAP, AJAX, Web services, all are used marginally.
and
The OpenACS community is dying or dead.
and of course, Lars' conclusion:
All the problems I’d seen weren’t because of poor execution. It was a dumb idea to begin with! Reuse-in-the-large is exactly the problem that OpenACS is trying to solve, and it “remains a mostly unsolved problem, even though everyone agrees it is important and desirable”. Can it be said any clearer than that?Problem is, that when you take away that piece, you’re left with an little known, hard-to-install, overly complex, partially debugged, aging toolkit built on a stack that nobody else uses. It started to look very unattractive. I knew I had to get away.
I find this kind of stuff distressing, but I really can't figure out what to conclude from it -- particularly since I also have had other far more optimistic discussions lately. Some random thoughts:
- What is the difference between a "mature" toolkit and an "aging" one? Now that OpenACS has finally settled a lot of the core stuff that was in rapid evolution earlier, it is now suddenly passe? Have the requirements for Internet-based database-backed applications suddenly changed and I missed some memo? How is it smarter to start over with some new first generation toolkit that has to re-solve all the old problems?
- Why is the "stack" issue such a problem for so many people? I guess that if you want to build/install systems that you walk away from and leave for maintenance to others who don't/won't know/use AOLserver/PG, then it is an issue. But if maintenance/support is part of your biz model or you're running the system/service on a box you control in some cage, why isn't the stack a black-box issue of no concern to clients? (Same point re installation.)
However, if the fate of AOL (eg a M$ acquisition) kills off AOLserver, then this is indeed a Big Problem for the OpenACS stack.
- The complexity and bugginess of the toolkit are indeed important issues, but those are always important issues. Is there any reason to think that a ROR system that does what a typical OpenACS system does is going to be any simpler? Here's what one of my post-OpenACS correspondents admits about that:
RoR is at the forefront of new technologies. Its real strength is Ruby, a marvelous OO scripting language. RoR's framework isn't suited so well for component reuse in the way of OpenACS's packages. Try combining a blog (Typo) w/ bug tracking (Collaboa) and you'll find that you either have to merge two code bases by hand or that you have to run separate web servers.
Yikes; this is less complex or prone to bugs? Maybe if you're simply running a blog, but an ecommerce site or clinical trials system? Sounds almost like a joke: "How many http servers does it take to run a ROR intranet?" And note the comment (near the bottom) in this ROR wiki that ROR should derive lots of stuff from OpenACS. So once the ROR community has built its own OpenACS, will developers then flee to the next kool new toolkit because ROR is "too complex"?
- I've presumed that the relative paucity of posts from core members here (like Don and Jeff, eg) is mostly because much of the core toolkit has stabilized and there's nothing much to say -- not that these key figures have gone away or aren't involved or interested. (Of course, if they would pop up and say this is the case every now and then, they could clearly dispel any such thoughts.)
At this point, OpenACS still appears to me to be a powerful platform to build complex solutions. I'm always looking for a better starting point (isn't everyone?), but I don't think I've seen it yet for the kinds of applications I find interesting.
