Forum OpenACS Q&A: Re: Why do you use OpenACS and .LRN?

Collapse
Posted by Michael Steigman on
Playing a bit of devil's advocate here... if all you get with a new release of OpenACS is the core toolkit, you are STILL getting a set or pre-written packages that work together, and a pretty impressive group at that: content repository, subsite, authentication, templating, administration, automated testing, et. al., not to mention a powerful permissions system.

As to the question about packages, I'm sure we all agree that unmaintained and immature packages should not be available through the repository for install. Unmaintained, mature packages are probably another story. This perhaps suggests another piece of package metadata - is the package maintained? I suggest that we either change the semantics of package owner and depend on the presence or lack thereof to tell us whether or not the package maintained OR we add a maintained-p element to track whether the package has an active maintainer (would be the owner). I know, I know, that's another piece of information that will fall out of date oh so quickly.

So, continuing to dream, I will ask whether it is really such a good idea to have critical information like this tied to the package .info file? There are probably dozens of users who could help with tagging package maturity or maintenance data if it were as simple as coming to the site and clicking a couple of buttons. Were that the case, we could integrate ratings/comments for each package, possibly even an overview page showing bugs and recent development. I don't think this would be too difficult to accomplish and could be tied in with the repository to give newcomers and veteran admins alike a more complete picture. Just a thought.

Collapse
Posted by Joe Cooper on
Hey Michael,

I just had to respond to this:

Playing a bit of devil's advocate here... if all you get with a new release of OpenACS is the core toolkit, you are STILL getting a set or pre-written packages that work together, and a pretty impressive group at that: content repository, subsite, authentication, templating, administration, automated testing, et. al., not to mention a powerful permissions system.

That's the definition of a web application development framework, and there are literally dozens of competitors (many written in a language I'm already familiar with). Those aren't end-user applications, and if that was all OACS consisted of, it wouldn't be the right software for me.

I'm not belittling the quality of the core OACS code. It really is nice and getting better, and as I mentioned, OACS is convincing me that I might like tcl. In another thread I've already talked about some of the cool stuff I like about 5.2.0. I'm just pointing out the one and only thing that sets OACS apart from the horde (no pun intended) of other frameworks and toolkits available, and the only reason I chose OACS, was the pre-written set of applications that fit my requirements almost exactly. Without the apps, I wouldn't be here annoying the members of this august body. I would be annoying someone on another forum related to some other project.

In short, I'm aware of those core packages...they just don't matter to me. No matter how good they are and no matter how important they are to the functioning of the high level applications I do care about, if I had to write ecommerce from scratch, I would have done it in Perl using the vast array of well-understood tools provided by CPAN and dozens of libraries and tools available for Perl. I'm here for the applications. Ecommerce, forums, bug-tracker, FAQ, etc. And because those packages exist, I'm developing (or paying Malte to develop) new packages, which are going right back into OpenACS CVS. As soon as I figure this monster out, I will be a pretty regular contributor on every package I use.

I think I'm the kind of user an Open Source project wants to have. I write books about things I love ( http://www.virtualmin.com/support/documentation/thebookofwebmin/ ), I frequently contribute patches (I've got lines of code in Webmin, yum, Squid, and even the Linux kernel, plus a dozen other projects that I've forgotten or aren't worth mentioning), I use the software in a real world environment with a couple thousand active users (growing at 50+ per week), and I'm noisy about bugs. And my real world environment makes money, some of which is going back into OpenACS development.

So, if all of these recent flammable threads are about how to bring people to OpenACS who will use it and help make it better...then I've made an honest attempt to make it clear why I use OpenACS. It's the apps.