Forum OpenACS Q&A: Re: Re: Why do you use OpenACS and .LRN?
Thanks for your detailed response.
I'll take this opportunity to once again say that I'm not bitching because OACS sucks and isn't the most effective tool for building a community website with lots of good services. I couldn't have gotten virtualmin.com running in 3 months with shopping cart, software registrations, forums, bug trackers, FAQs, and user management, with any other system. There is no competition for OpenACS (Plone/Zope is broken enough for me to put it in another class altogether), OpenACS stands alone, so OACS can be as poorly documented and ornery to use as it wants to be. But I'd still like it to be better. 😉
So, to make my following comments a bit softer: OpenACS rules! I love OpenACS! It saved me many months and many American dollars worth of development.
Now, back to the ruthless bashing that everyone by now has come to expect of the ingrateful barbarian from the hills of Texas:
OpenACS 5.2 includes some powerful, new features. The subsystems, including Postgresql and TCL are evolving as well. Development is ongoing to improve the toolkit performance and comply with standards in more ways. Sometimes this means writing new code. Isn't it a good thing to be continually improving the toolkit?
Certainly. If the toolkit is what OpenACS is really about (and I'm in no place to say that it isn't). My complaint is with the fact that the changes are made to the core, with seemingly no regard to breakage in non-core components. About 50% of 5.1.5 application packages are broken in small or large ways, and bug reports about most packages are ignored. Even more packages are broken for 5.2.0 in some way. If the OACS development toolkit is what OpenACS.org is all about and applications are just for fun, the website and the policy needs to say so. I chose OpenACS because it appeared to be a set of pre-written applications that worked together. I wasn't looking for a toolkit (and I passed on Catalyst, Mason, RoR, and several others because they provided the toolkit but not the actual applications), but to some extent that's what I ended up with (though admittedly, there were a lot of almost-there applications that I could start with, which is lacking in most other toolkits). If the OpenACS developers want it to be a development toolkit, say so. It is presented as a set of working solutions based on a common core toolkit. As has been mentioned, the package stability problem is known and the maturity flag in packages is probably a good start for dealing with this problem.
Let me be blunt, so everyone knows where I'm coming from:
The vast selection of packages is what makes OpenACS attractive at all to users like me. There is nothing else in OpenACS that makes me want to use it over something in Perl like Catalyst or Mason, or, if I'm to learn a new language, RoR or Seaside. If the packages do not matter to the OpenACS developers, OACS is not for me. There are exceptions, but the majority of packages appear to be of no concern to any active developer. I am in no place to say what people spend their time on...but if packages don't matter, OACS can't matter to me. I'm not a web application developer...I use OpenACS to sell and support software wholly unrelated to OpenACS, and if I have to make my full-time job working on OpenACS, my actual business is going to fail due to lack of attention.
That depends on your reference point. OpenACS 5.1 is the stable branch. The core packages of OpenACS 5.2 has just been released. This is when work is done to make the other packages work with the new core (if not the new core features). Some cvs changes were made to the 5.1 branch that should have been destined for 5.2. Those can be corrected by reversing changes in the 5.1 branch. The cvs browser ( http://cvs.openacs.org/cvs/openacs-4/packages/ ) has a nice feature that lets you see all the contributions that make up each page (called "annotate"). That can help identify recently made mistaken commits.
My reference point is 5.1.5. That is what runs on my production server, and on my devel server until a couple of days ago. The assertion that 5.1.5 users should use the CVS browser to figure out what code they need to change to make 5.1.5 packages work is a bit frightening to me. I'm not afraid of CVS, and I'm not afraid of patches. But...really? This is standard OACS production server practice? Is there any documentation about how to do this?
I'll refrain from comment on 5.2 from here on out, as I now understand that it is a core library release. My complaints about broken packages apply to 5.1.5 as I downloaded it and the packages from OpenACS.org. I don't know how to do anything other than install the stable release and the packages provided by the software repository, and those packages are often broken and unmaintained.
The bugtracker needs to be optimized to become really effective in its current role. For example, it's really difficult to get a full, summary count of open bugs. The bugtracker presents counts of all bugs (open and closed), which has limited value for continual improvement. Indeed, I know some think that the bug counts refer to open bugs, yet the count of bugs only increase, even when they are closed!
You're saying this summary is not correct?
Open 819
Resolved 399
Closed 1539
I'm not sure how closed could be higher than open if things act as you describe. But, I believe the summary is correct. I've just browsed out to the end of the pages of open bugs (33 pages with 25 per page except on the last page which has 18==818 bugs...one went missing, but close enough).
But, nonetheless, there are bugs that have been open for years with no activity. Sure, a lot of them are not valid bugs, many have probably been fixed but not closed, etc., and some have running commentary as someone addresses small parts of the larger problem reported by the bug. The point is that some go years (years!) without activity.
I have no problem with there being lots of bug reports--every large piece of software has lots of bug reports, and a bug tracker is a great way to keep a todo list. But it is clear that there are some aspects of OpenACS that are simply not maintained. It wouldn't matter (much) if the API were stable, but as it is, many apps don't work on the current stable release of OpenACS and I see no reason to believe 5.2 will make this problem anything but more pronounced.
In summary: I view the steadily increasing breakage of packages as a huge problem with OpenACS. I have no right to demand anyone hold the same opinion I do on the matter...but if anything sends me and my development time/money elsewhere, this will be it.
Yes. Prior to OpenACS 5.0, ecommerce was published as a toolkit. Now a demo/test site can be setup without having to actually write (much) code.
I can live with that. I didn't know that. But I can live with it. My store took about two months to get up and running (some of that was a new package to support software registration that Malte mostly wrote for us). I could have done it faster with other shopping carts, but I wouldn't have gotten the forums and bug-tracker and FAQ and news. Overall, I'm happy. But it would have been nice to know when starting out that ecommerce requires new code to even work.
I made some bad assumptions about packages early on. Now I beta test everything outside of an implementation site before implementing it or making any commitments about it.If I had known the actual state of packages in OACS, and how much time I would spend figuring out that "this one doesn't work in multiple subsites, so we can't use it yet, and this one doesn't work if you have more than one instance, and this one just gives a traceback and hasn't been touched in CVS in two years, and this one doesn't uninstall without a traceback, and this one only supports Oracle despite apparently having code for PostgreSQL", I might not have chosen to use OACS.
Oh, I have a devel server. Nothing about these broken packages is causing my customers distress (generally). But one can't know the state of a package until one actually installs it and spends time with it. The maturity attribute is an excellent idea, and I hope it will make this problem less irritating.
The point of this particular rant is that I came into OpenACS with big plans of making use of many more applications than I ended up using. It's difficult for a newbie like me to know when a problem is easy or difficult to resolve. Sometimes I've put in the effort to fix the code so that it runs after ten minutes of reading and code prodding. Sometimes I've tried valiantly and failed. And sometimes I've given up as soon as things went south, because the errors looked too scary for me to think about. But a lot of time has been wasted in the process, with not a lot of useful OACS development knowledge gained.
Actually, there is. It helps to have a development sandbox for each of the different versions one is using or wanting to use. Check the prior version's api-doc (version 5.1 in your case, which happens to be the same as OpenACS' at https://openacs.org/api-doc ) for info about what replaces it, usually under "See Also". For example, see: https://openacs.org/api-doc/proc-view?proc=ad_ssl_available_p
Excellent! I didn't know about this. Consider this complaint rescinded. Unless and until I discover that these docs are outdated and/or inaccurate too. 😉
Anyway, OpenACS is without a doubt the best set of integrated (kinda) web applications available, but it's also the only one...so it's hard not to be the best when there's no competition. But, if things continue going the way they have been going since I started using OpenACS and more packages break with each revision, it will become just another web application development toolkit. And with the unfortunate words tcl* and AOLServer* in the description, gathering new users and developers seems unlikely.
*-I have nothing at all against tcl or AOLServer, and in fact, I enjoy tcl now that I've used it. But my python and ruby and perl developer friends literally cringe, groan, or shiver when I say my website is developed entirely in tcl. Bad wrap for tcl, but them's the breaks. And, of course, the letters "A", "O", and "L" are poisonous for most nerds. Again, bad wrap for what is actually pretty darned good software, but it's the reality of the market.
