Forum OpenACS Q&A: Request for Comments and Discussion: Building a Leaner, Meaner OpenACS with MIST

Over the past few months, I've noticed a number of issues caused by the growing size of the OpenACS core. It seems we are missing out on the inherent modularity of OpenACS and involuntarily heading towards a monolithic release the way we used to deal with 3.x

Many others have noted this, too. I've spent a few weeks collecting ideas and putting together a proposal for how we might fix this with a bit of clever technology. I'm calling it OpenACS MIST (Magical Installation and Setup Tools), and I'm anxious to see what people think.

This post is meant to foster discussions: nothing on this project has been done yet except for putting together the proposal.

Check it out at http://openforce.biz/openacs/mist and please post your feedback!

Well, i read the whole proposal, and my approach to this issue is
as a new developer and end user. One of the "problems" i see with
it is that these out of the box "distributions" i.e. dotlrn, etc.
are not very hard to set up - sure CVS isn't that fun, but once
you have APM's of dotlrn, etc. its pretty easy to do - thanks in large part to the package manager and *.apm files.

Given that currently people need to know how to compile
postgresql (or worse install oracle), aolserver, make them
automatically start/stop and respawn themselves, etc. change user
profile settings (i.e. bash_profile, etc) before being able to
install openacs, I don't think the ease of install MIST would
provide would be necessary given that user base already needs to
be reasonably computer savy to get to the point where they get
the core working and are able to use MIST... If all one needed to
do to get the core running was to apt-get openacs, or rpm -ivh
openacs, and if that took care of postgres, oracle, aolserver,
etc, setup, as well as the service monitor, (possibly even Image
Magik) and all of the that, then openacs would be catering to a
different group of people that might find the install scripts
helpful, but I don't think the current user base would find it to be very important. And i'm not sure if openacs should even cater to the user base that needs rpms and deb files... websites inherently need to be customized, and you need to be reasonably savy to do that.

I do like the idea of clearly defining a core and separating
packages from that core as much as possible, but the automatic
install aspect of MIST doesn't seem to important to me (as a new
developer/end user). It would be nice to have
packages.openacs.org, as a shared ftp type server (though most
likely with file-storage on top of openacs) so anybody can
upload a module they create with a description of its application - but it sounds like this is already in the works.

I agree with Don that getting the whole tarball is a nice thing. This is what i do with Linux Distro's just like he says... hard drive space is cheap (especically when were are talking about less than 100MB no matter what), and it is nice to get everything... that doens't mean it all needs to be activated, but there is no harm in having it sit and take up space on your server... it isn't that much space after all. Same things goes for linux distros - i always install everything from the beginning, and just deactivate it until it is needed... much like openacs distros.

The more I read, the more pissed off I get ...

We know the answers because we just changed our name to Open
Architecture Community System. OpenACS is an architecture for
online communities. Thus, as an architecture, it defines how various
pieces of code are going to interact with one another. It does not
define all the features that will ever be part of an OpenACS
installation. It defines the object system, the permission system,
the package system, the request processor. It does not define the UI
or specific end-user (forum, calendar) functionality.

"Being part of OpenACS" should simply mean that you:

   1. adhere to the OpenACS base APIs,
   2. build a compliant, good-citizen package, and
   3. generally follow the OpenACS development style guidelines. 

But does your package have to be distributed with the OpenACS distribution to be "part of OpenACS?"

No. In fact, going down this road is dangerous: it creates bloat in
the core distribution of OpenACS, complicates the learning curve, and
generally makes OpenACS far too monolithic.

Our current thinking is leading OpenACS 4.x down the monolithic, un-modular 3.x path. 

This is a total misrepresentation of current thinking.

I concur that the plan has been to move away from monolithic releases, and work has been put into the new openacs web site to have the infra-structure to support separate projects (with subsites, the different projects under /projects have their own subsites already). We'll even have separate downloads, separate bug trackers, etc.

So perhaps there has been some miscommunication there, so let's look at this objectively.

Regarding the especific issue of new-portals being merged into the OpenACS core and used throughout administration (instead of just being "distributed" in the OpenACS tarball), I don't know all of the issues there, and I think it is the matter for a different thread.

MIST however adds something really interesting to OpenACS, which I had toyed with in my mind while trying to figure out how to go about creating Debian packages for OpenACS and the different vertical applications based on it.

With MIST, my Debian (or other types of binary packaging) would just include automated MIST scripts to install everything the user wants.

I don't know all the political implications of this proposal, but as a user of openACS, something like MIST could be very useful to me.

First of all, I'm in total agreement with everyone that a monolithic openACS is not the direction the toolkit should be going.  I'm glad that most involved in development see this need and are talking about it and making plans to make it more modular and easier to handle.

In addition, I think MIST is a great idea that should be considered and discussed on its technical merits.  It is true that most users of openACS will need to be pretty savvy to get everything installed correctly, but for the most part this only requires some attention to the docs and some unix/linux experience.  With the current way of setting up a site, you have to have a pretty good familiarity with the toolkit in addition to being comfortable in unix.  This is something that not everyone will have right off the bat.  Being able to choose an "distribution" that contains only needed packages and is set up close to the way the user wants will allow him to gain experience with openACS more gradually, while giving him a good, functioning website with a minimum of previous openACS knowledge.

Personally, I could see myself making my own MIST scripts to help speed up the process of installing my own websites to get a base of common packages I normally like to use.

Ben, i hadn't thought about the added complexity of dotWRK or dotORG... i guess it would make more sense then... since i'm still new to openacs i'm not as aware of all that is going on in terms of side projects... and more importantly how independent/dependent on the core they are. i can understand the idea of sepearting things such as the core from Linus vs. distros like RedHat, SuSe, Mandrake, etc... so i think the idea certainly has a lot of merit, though i think that given the reasonably small number of packages currently available, that it isn't currently needed... linux distros on the other hand have many, many, many software programs... so it is more necessary. That is not to say that it wouldn't be nice, just that i think a solution to this "problem" isn't currently needed or highly sought after. Though this is the opinion of money newbie that is just trying to work on his first two packages... so take my opinion about the core as a reasonably uninformed one.

Apologies coming to this one late, and I'll avoid raking over whats already been said, but I do have to agree with Don's comments. I went and read Bens doc, before going through this thread and was left with exactly the same impression as Don.

I'm aware that for a long time everyone has agreed we need to address this a move to a more modular approach, and its been time and resources held that back.

Having skimmed your document Ben, I generally agree with the approach (but I need to consider it in more detail).

But... your tone, and the unnecessary ramblings which *do* seem to be taking side swipes and highlighting positions that simply don't exist is not all that constructive.

Let me take just one choice example

'Our current thinking is leading OpenACS 4.x down the monolithic, un-modular 3.x path.'

This kind of comment is unfair, untrue and unhealthy... So why's it in there Ben?

I can see you may have an evangelical or political persuasion on this, but mixing it up under the premise of a proposal is a little, tiny bit underhand.

Would it not have been better to put up a *neutral* proposal for what you'd like to see, and then post separately if you want to soapbox, making it clear thats what you're doing?

And of course, checking that something is *actually the case* before you throw it at us!

It seems the discussion is not about configuraton tool (MIST), but about architecture. If OpenACS project adopted layering pattern, it could be easier to maintain and extend. The question is it OpenACS objective?

The essence of the pattern is that lower layer provides services only to upper layer. Lower layer never depends on upper layer (i.e. core OpenACS never depends on dotLRN). So architecture looks like this:

1. System services (Linux, Postgresql, AOLserver)
2. Foundation layer (authentication, objects.)
3. Core application layer( forum, news, portal, calendar etc.) aka "business object layer" -a set of basic applications to solve problems in a particular domain (in OACS' instance - task of building online communities; but somebody may build a set for building stock market trading system, for example)
4. Standard Applicaton layer (ready solutions for more specific task, such as community aimed at learning: dotLRN; or a "typical" blogger community for news discussion, or a web-store with attached community of customers (does it ever work?) etc.
5. Custom applications done by customers to their own needs.

As you already noticed, it looks aufully like Enterprise Java. Nothing wrong with that, but with all those layers you may expect slow performance. Besides, it's inefficient trying to do object oriented programming in scripting languages like tcl. Why not direct in Java then? The language was designed for this stuff, after all. Example of ezPublish shows - you can build decent object-oriented framework with PHP, but it will be sloooow... And you never achieve stability of Java anyway.

But hear this. On the other hand, if you "compress" above core layers 2 and 3 into a monolitic OpenACS, you will still be able to provide basic services needed to build online communities. This application will be very difficult to upgrade and maintain, but who cares since people will be constructing new "types" of online communities on top of that (learning community, shoping community, political party, religious group etc). As far as core service set is stable and doesn't change (forum is forum after all and news/comments are news/comments) - nobody cares if there is a "expandable" object framework under it. Eveybody cares for speed and stability, though...

You can go even further and stuff your code into database (triggers and what you got), simplify your table structure (and break your neat data object framework) - and you can achieve a blazing speed for your application. This will lock OpenACS in PostgreSQL and Linux, though. Or you have to write another OACS for Oracle, more or less.

If anyone remembers, Greenspun had argument against using n-tier architecture in ACS. Why create layers when you know exactly what web services you will need in the end? Do most online communities need stock quotes? Do most communities use Windows? What is obvious enterprise-class database? So, ACS was made monolitic, married to Oracle and Solaris. Point. The system could scale up like a beast on a simple machine. The same machine that would choke on its first EJB...

So, I would argue 3.x system was made monolythic on purpose as one big "business object" that is stable, fast and provides only basic services to create online communities. After that all creativity and talent of the aD went into creating business applications with the toolkit.

Which path OpenACS community will chose, depends on its members vision. I see danger in trying to build Enterprise Java-type of busness object framework in tcl, however challenging it may be. On the other hand, if layers 2-3 (above) are made stable and optimised for performance - you have one great core business object for community building, including built-inIDE to create application like dotLRN - and many new ones. That is what I see as differentiating and unique feature of OpenACS under the sun.

Ignoring the resource issues, MIST looks cool.  For a long time my own personal nirvana has been a web-aware package manager than can query the various repositories and tell you what's new and what's changed.  This way you could just click "Install" instead of having to wget/untar/install or copy/paste URLs into the package manager web UI (the way it used to work before arsdigita.com went offline).  Perhaps this is the up2date to MIST's apt-get.

In a world of limited resources, however, I agree with Jun.  My money would be on making OACS easier to install.

Regarding new-portal.  Up to this point I haven't participated in the discussion.  Clearly this is something of a pandora's box.  Politics aside, it seems like there is room here for good-natured technical debate.  On the one hand, there is a big advantage to using new-portal for admin pages.  Namely, you get nifty auto-generated admin pages that expand as new packages are added to your system.  dotLRN showed us that this is possible not to mention very cool.  But the downside, as Ben points out, is that it adds yet another required package to OACS and generally raises the bar for writing new packages.  To me this seems like a reasonable concern.

Perhaps the right solution is to have "fancy" and "lite" admin pages.  The "fancy" pages would work like dotLRN and require new-portal.  The "lite" admin pages would query the site map for all instances mounted under the current subsite, and link to package-key/admin for each instance.  This way we could take advantage of new-portal when it is available, but not require it.

Hi John,

Thanks I am aware of your work.  I hope it does work out fine.  That way we can have an OpenACS that other people can try out that only depends on tcl and postgres, or other people not willing/unable to install Aolserver.

Igor,

Good points thanks for reminding us about it.

Roberto,

As you probably know I *rarely* post flames of any kind. But I reserve my right as a member of this community to express my opinion and respond to posts.

As you will see I have commented on the technical aspects and the architectural ones, but given that Ben's original document was a proposition based on a number of his observations/arguments, I am also going to comment on that.

I certainly resent your apparent 'chastisement' of my posting. I put a lot of time (and company money/resources) into helping out here and I for one am not going to sit quietly whilst Ben using derogatory, dimissive and frankly bloody innacurate descriptions of the current state of OpenACS. *That* is certianly no help to anyone, and very damaging if it gives off the wrong picture of the current state. These BBoards are not mere soapboxes for Ben (or anyone else) and I'm sure he understands that.

But hopefully now I'm sure Ben will have taken the comments on board and we can now stick to discussing the actual substance of his proposition. In which I must add I am very much interested.

Apologies, I mistook the tone of your reply :)

(I've only done the <h2> thang once.... honest)

Yup, couldn't agree more.

On a point you raised, I have had one or two people tell me they are bothered by the size of the distribution, but they don't mean the download time, they actually mean that for a newbie its 'looks' like a lot of stuff and thats a bit daunting. I guess, now I think about it, if I hadn't come across it before, it does seem quick a bit of code there.

But I think it not a question of splitting up bits, but could be immediately and effectively releived by improved introductory documentation explaining whats there, whats important, what you don;t need to worry about initially.

another threads been raised about documentation (with which I agree) so I'll leave further discussion on the to that thread

Cheers

Thanks to everyone for posting their opinion. I encourage more people to post, even if their post is as simple as "I agree with person X." Jun, specifically, you have nothing to apologize for. I want to hear arguments from all sides.

A few responses:

• Don, Simon, Dan: I've had 4 people re-read this document with me. I've reread it myself 10 times at least. I don't mention anyone by name, I don't ever imply that anyone has done something wrong, I say that we are going down the wrong path. we includes me. This is not a criticism of anyone.

• Dan: the current OpenACS distribution is only getting bigger, with nothing ever being taken out. Both the core and the tarball. This is not opinion, this is fact. All you have to do is check the CVS. And since OF has contributed to this, I'm once again not accusing anyone, simply pointing out a fact and a potential solution.

• John: ideally this puts no more stress on developers than putting together a MIST script, as you said. But your worry is a good one, and we should keep that in mind if we move to actually planning development of MIST. If MIST ends up making developer life too complicated and user life only moderately better, then it's not worth it. Thanks for pointing this out!

• Andrew: right on! fancy-ui and simple-ui is exactly the kind of idea that I want to see with MIST. If people want portals-based UI, they should get it, but if it doesn't need to be imposed on everyone else, then why not make it modular?

• Simon: I think something like MIST would *help* on the testing front, meaning you could stagger testing of different packages and begin doing more unit testing instead of the monstrous integration testing you have to do every time. You're putting in an incredible amount of work to do this (and thank you!), which I think could be eased a bit.

• Simon: yes, currently, dotLRN has to be downloaded as one big tarball. Not because of dependencies (we've done the best we can to be as modular as possible), but because in a world without a MIST-like system, how else can we do it? That's why we're proposing MIST, so that people can use parts of dotLRN without downloading the whole tarball.

• Simon, again: context is important. From a technical standpoint, location of code shouldn't matter. From a management standpoint, it matters very much. MIST tries to make location unimportant so that management of code can be performed in whatever way the code's author prefers.

• Don: you say "there's no point in writing MIST if we can't gather the proper resources to properly manage module releases." I say there's no point in modularizing releases if we don't have an end-user tool like MIST to keep it simple (and even make it simpler) to install. This is what's worth discussing! Let's hash it out.

I'll try to summarize again the points here:

• yes, many people, including Don, Dan, myself, Simon, etc... have expressed the desire to move to decentralized packages. I don't question that.

• at the same time, we haven't really done anything about it to date. Discussion doesn't count as action. That's what I claimed in my proposal and what I continue to claim today.

• if we do something about it without something like MIST to make installation easier on the user end, then we will find ourselves with an even less usable system, or force users to resort to whole tarball downloading... in which case, what's the point?

Once again, I am not cricitizing anyone in particular. Check out the proposal again. I say "we". "We" are a community. "We" includes me and OpenForce. We're all in this together.

Yes, I think on the whole I agree with how MIST should work, but I think I'd nbeed to think a bit about the detail before posting up much more on that.

However I do want to point out that my understanding has been for some time now, that a more serious effort on modularisatio etc had always been anticipated to occur around or just after the 4.7 release. So far from not making any progress, as far as I'm aware everyhitng moving forwarg against a timescale thought practical.

(PS, I still feel the tone of you original document was unnecessarily critical,and I still feel you are over stating somewhat the current situation and the priority/seriousness of the current deficiencies)

Yeah, but I think it turned out that further investigation showed that the memory consumption for the query file cache, etc was just a few MB, right?

Query files aren't cached unless the package is installed, nor are Tcl init files sourced.  A core-only install, then, doesn't eat memory based on the number of uninstalled packages which happen to have been dumped in your install directory.  Changing the distribution methodology wouldn't change the size of the minimal footprint, then.

Removing some things from the core install, say the content repository, would shrink the footprint but that's true independent of the physical means by which the toolkit is distributed ...

Simon - another Japaneese proverb - poorly translated; you find what you look for

(Good grief. What on Earth happened to my spelling in that last post??.. I need to lie down 😉, sorry about that folks)

Perhaps you are right Igor. But perhaps not.... hence we debate, hence we argue, and hence we (rightly) cry foul when our we feel our positon to be mis-communicated.

Thanks for the telling me off though... consider me suitably chastened...

The MIST proposal is three things:

1. Move away from monolithic releases
   Everyone agrees that we should not have single monolithic releases of all packages. It's unwieldy and makes the release interval too long.
2. Provide a Configuration Management tool
   Important to have and hopefully someone will step forward to write one. It's not clear that it has a lot to do either with having a central package repository or whether we do monolithic code releases or not.
3. Provide a Central Package Repository
   Again a good thing, someone should write one and fortunately APM is almost there. The metadata you would want to keep is in the info files already and all we would have to do is have a place to upload/post .info files and little bit of code to manage it. Unfortunately the current metadata in said .info files is complete crap. Hopefully if it meant something people would spend a few minutes cleaning them up.

Broken down like that what are we left with? Three relatively uncontroversial proposals and as Andrew (and Don) mentioned limited resources to put them into place. If done right they might help on a lot of fronts but need to be considered in light of other priorities.

On monolithic releases; I consider it a waste that we do not leverage CVS. If we used CVS properly and maintained a stable and dev branch we could do relatively frequent bugfix releases from stable and rapid cutting edge development on dev.

It is really little additional work and we would derive great immediate benefits, the biggest being that on stable we could limit data model changes to those with well tested upgrade scripts ensuring that production sites would be able to get bug fixes and be more confident about installing new packages.

Maintaining a central CVS repository makes merges dev<->stable much easier. and provides a great deal of transparency.

On configuration; ultimately, configuration is an awful lot more than just which packages you install and where you get them, and it's something we definitely need to think about. Although when I consider the state of the documentation I am not sure the effort is not better spent there rather than on a complex feature complete tool.

Also, From a purely technical standpoint I think I am leery of using a config tool which has Tcl code in it or depends on a lot of other tools to be installed. My preference would be for it to be data driven much like the current APM, although I guess I could be persuaded that the flexibility afforded by such a scheme might outweigh the dangers (the temptation to hack things in instead of using a clean Mist:: API, the risks of wiping out existing configuration data, obscure hard to reproduce bugs etc).

As for a package directory/repository, I think a central place to record where different modules live is great, and a download repository is great as well, but I think an awful lot of projects get by on CVS and tarballs and I think that's good enough for now.

All this is a long winded way to say that all the ideas are good ones and should figure in the plans for OpenACS but the problem is now (as it has been) who will write the code and is it what we want to spend those resources on. I don't believe either of the two code things are the most important things to be focused on, and I think we can avoid monolithic releases by simply overhauling some of our practices and educating developers about CVS. My list of major issues are:

• Documentation -- it is currently "not so good"
• Looks -- also generously described as "not so good"
• Bugs -- too many

I think we need to develop a consensus about what's important and encourage prople to get the important things done but bear in mind that it is individuals and volunteers doing an awful lot of the work and people generally will do whatever the hell they feel like doing. If Ben/OpenForce wants to write the code and make it stylish, beautiful, and (yes this is a dig) somewhat better documented than their recent contributions, then that is great. If not, unless it tickles someone else's fancy or someone wants to pay for it, it won't get done.

A few more answers:

• Dan: you're implying that if I say anything negative about OpenACS, I'm insulting Don. Should I just shut up unless I have good things to say, then? I see certain issues, and I try to propose solutions that we can all discuss. There is nothing disingenuous in what I'm saying. I am not blaming Don. If anyone thinks I'm blaming Don, they are wrong. I didn't blame him in my paper and I'm not blaming him now. I simply think we all have made a mistake in delaying something like MIST. I'm looking for rational discussion around that idea.

• Dan, again: I think the core was already too big when aD released it. And in fact, I seem to remember that we all agreed on that. We recommend using acs-mail-lite instead of acs_mail whenever possible. We agree that acs-messaging should probably be dumped. We agree that acs-workflow should not be installed as part of the core. Some don't want content repository installed by default, either. So let's do something about it. It wasn't right 2 years ago, and our lack of action doesn't make it any more right today.

• Don: agreed that we can shrink the toolkit size without MIST. That's an excellent point. Now, I'm not so much pitching a new way of breaking things up, I'm pitching a new way of putting them back together for users. If it's easy to put things back together, it's an easier decision to make to break things up.

• Jeff: great comments and great analysis, thanks. I initially thought about an XML-driven MIST, but then I realized that the installation itself might be a bit more functionally-oriented than data-driven. But certainly nothing is set in stone, this is just a proposal. Understood about the documentation complaint. We're trying to fix this first by doing the new-portal cleanup with documentation in parallel.

• To clarify, the source code for new-portal is available to Janine, who manages both dotLRN and OpenACS, and she can make any decision she wants on what tarballs to include it in: the code is owned by MIT Sloan and managed by the dotLRN boards. OpenForce is only wrapping up cleanup and documentation as a means to help future work in that direction, and will provide that code ASAP to Janine for inclusion in whatever version of OpenACS and/or dotLRN she sees fit.

• Jeff, again: OF is definitely willing to contribute resources to build MIST, sorry I didn't make that clearer. That's why we're making the proposal, to see who would find this useful before we put time into it. No client is paying for this. This is definitely not a request that current volunteers shift their focus to MIST. This is what I'm interested in and I thought it might be useful to more than just me, that's all.

• Simon: on the contrary, MIST is meant as an end-user tool to enable end-user configurations. Developers would use MIST only when it comes time to package a distribution of the stuff they've written.

No, you're welcome to criticize, and you're especially welcome to help
rectify the perceived problems, but the tone of your proposal suggests
that you have another hidden agenda. In addition, you're rehashing a
problem that has been discussed at length before.  If you trimmed your
document to a strictly technical proposal, it would be less than half
its current length, and we would currently be arguing the technical
merits of it instead of having this fruitless discussion.  Even
better, if you had offered to implement it, your proposal would have been warmly received.

Yes, acs-messaging should go, and acs-workflow should go, but I'm not
so sure that the CR should go.  In past discussions, we agreed that packages
should move towards using the CR, so that common services like search,
categorization, etc. can be enabled easily for supporting
cross-package aggregation of content management.  I think it was a mistake to not base the new forums packages on the CR, since we now have to add additional code to support searching and categorization of forums that otherwise wouldn't be needed, if it had used the CR as a base.

We don't need to use mist to rectify this problem. I could go into cvs
and easily fix that problem right now, if we had a consensus to do so.
If you wanted to change this, you could have done it yourself (years ago) after a
short discussion on the bboards.

Dan, you say: "even better, if you'd offered to implement it, your proposal would have been warmly received."

I'm very sorry I didn't make that clearer. I thought it was implied when I posted the proposal, but apparently it was not: OF is definitely proposing to put development power behind this. We'd *like* to work with the rest of the community who's interested and who's already working on packaging, but certainly we meant this as something we would take the lead on.

Oh, I forgot to mention that I imagined that OpenForce would contribute resources to the implementation of MIST.  I understood that as clearly as I understood Ben's non-too-subtle swipes at me.

However ... I'd much prefer that for 4.7 we coherently try to prioritize shortcomings and problems in the toolkit, encourage people to make proposals for work on the toolkit they're interested in pursuing, to try to set a rough schedule for code freeze and testing, and to then - as a team - finalize a set of things we want to accomplish in this release.

And I'd then prefer that OpenForce work as part of the team to make sure that work items that make the cut for 4.7 actually get done.  A distribution tool like MIST may or may not survive a prioritization process for 4.7 (or 4.8 or 4.9 or ...).  Actually I'd prefer we set forth problems and prioritize them first ("bug fixes", as Jeff Davis mentions, is high on my list; so is "scalability", still an issue) and explore proposals to solve them afterwards.

Software projects need to be carried forward in a disciplined manner.

*ahem*

As the resident Release Mother, err I mean Manager, I have a request:

Could this discussion please be tabled until the 4.6 release is out the door?  I think it has become a huge distraction and I need the attention of many of the folks who are posting to this thread.

Perhaps we could have a general rule that no non-emergency distractions should be brought up between code freeze and release?  At least for these smaller releases, where the time frame is pretty short.  Considering how thinly stretched our resources are already, I think this would be a big help in getting the things done and out the door.

I could go on at length about my opinions on the subject at hand, but I'll be the first to set a good example and keep them to myself for the moment. :)

Ben, Good Ideas. However, let's walk before we run. We could use your assistance with the basics, such as getting OpenACS and dotLRN released. Many of us are trying to pick up the pieces after OpenForce pulled out of dotLRN with a lot of unfinished business.

Al,

Your comment that OpenForce has "pulled out of dotLRN" seems to imply that OpenForce will never do anything else with dorlrn on help in its development as an open source project. Is that the case or has OpenForce only refused to participate take a seat in the TAB (technical advisory board)?

My understanding was that it was the latter, and it's an important distinction.

The more I get to know Ben and think about how he thinks (e.g. dotLRN, MIST), I am convinced that what drives him first and foremost is aesthetics. I have the utmost respect for that and believe that the community is very fortunate to have him as a member. Sloan is the beneficiary of wonderful work achieved by Ben, Yon, Arjun and the OpenForce team in developing dotLRN. I don't always agree with Ben, but I  don't question his motives and will always regard him as an inspiration.