Forum OpenACS Q&A: Re: Why do you use OpenACS and .LRN?
Joe, let's address your greatest disappointments to start with:
The original implementors of ACS were wrong about everything they ever did. At least, that must be the case, because everything is being re-written by every developer in wholly different ways (it also appears that every current developer is also wrong in every possible way, since everyone writes their own everything from scratch and doesn't document it).
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?
Packages are more broken today than when I started using OACS a year ago.
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.
One cannot count on any of the packages actually working once installed--even many reasonably new ones are broken in 5.2.0. Apps that were broken in 5.1.x when I started working with OACS are still broken today, and bug reports result in no changes...sometimes even the patches I send take months to be applied or don't get applied at all.
Again, 5.2 is not stable yet. The reality is that some bugs in 5.1 will likely not be fixed, because developers would rather make a "better" fix in 5.2. etc.
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!
.ecommerce is still utterly unuseable in the state that it comes down from OACS.org and doesn't work at all in 5.2.0).
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.
..it's time for packages that haven't been touched in a year or more to be marked unusable/unmaintained.
There is a package maturity attribute that is being implemented which should help with this. https://openacs.org/doc/current/releasing-package.html In any case, it is in deployers best interests to test everything before implementing.
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.
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.
Documentation is copious but wrong. And difficult to read, due to an odd docbook processing quirk that has never been fixed (the doubled up shell output).
You have misidentified a feature as "wrong". The feature was added so that one can copy from the document and paste the code directly into a shell window. See: https://openacs.org/doc/current/install-steps.html#how-to-use
APIs are constantly shifting with no documentation of the changes. After upgrading my devel site to 5.2.0 last night, I became aware of a huge swath of deprecated functions in most of the modules I use. I wasn't aware these functions were being removed.
Me neither. Somehow I missed the warnings in the error log whenever the deprecated functions were called.
Worse, there is no map of what functions replace the deprecated functions.
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
it seems that my focus is quite a bit different than most folks here, since a lot of focus is on dotLRN and major overhauls of the core APIs
Maybe, but I doubt it. Each release is a significant improvement over the last, quite a bit of it in the direction you are wanting to go.
Joe, perhaps the following hints will help:
When you are uncertain, ask. I had to drill that into myself. No one knows your OpenACS struggles and therefore cannot help if you do not make the problems known. How much time I wasted early on, when a simple question or comment to the forums or irc channel could have helped.
Learning OpenACS is about learning how to find answers, and how to use the various subsystems fully as they evolve along with OpenACS. Learning OpenACS style is not a cliff, but an endless spiral of continuous improvement cycles. Pace yourself! Also, a little karma yoga helps! =)
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.
