Forum OpenACS Q&A: Why we should dissolve the .LRN consortium

.LRN (the consortium) should not (and will not) be dissolved (without some MAJOR arm twisting).
.LRN should be just another OpenACS configuration option (and we still have some serious work to do to make that happen).
.LRN should support a push for a general OpenACS installer (in which .LRN is just another configuration option).
.LRN and OpenACS should make it a point to share as much focus, direction, and discipline as possible.
.LRN should continue to promote the adoption of OpenACS (especially when adding .LRN specific applications will just be a few clicks away on the APM install web page).
.LRN and OpenACS share the same community (right now), but that will not always be the case.

The goals behind .LRN and OpenACS are similar but different.
.LRN's strength is OpenACS.
There are advantages to having a .LRN brand that we have just begun to build on.

If this is more than just a socratic question Al you should TIP it (a suggestion Don just made to me that I like): https://openacs.org/forums/forum-view?forum%5fid=115570 which should keep this discussion short. ;) I am going to go have another beer.

The last comment I want to post here about the OpenACS brand has to do with one of Roc's posts in your last thread (a very motivating one btw): I am starting to get sick of that "gay dog" too... especially since he is no longer helping (and OpenACS has outgrown him).

Currently .LRN is used for two different things. On the one hand the software package that should be an installation option of OpenACS, enabling us to have one release system, one project one community and one technical governance.

On the other hand we have the .LRN brand cum consortium. The brand is getting established in the area of higher learning and is therefore valuable and should not be demolished lightly. The consortium on the other hand is an entity of *users* that gives new adopters a good feeling that they are not making a mistake by choosing .LRN and gives them security that there is an entity coordinating the needs of the users.

Coming back to Tracy's comment about the two different release circles, I think we should make sure that we release the packages along with the core. All packages with a certain maturity level should be part of this release process and this should be reflected in an extra maturity level four which adds to three the point "has undergone the official release circle along with all release criteria".

Jeff touches on something I want to emphasize. In the past year or so we've achieved our goal of moving AWAY from monolithic releases of the entire toolkit. Short term, that probably makes OpenACS look less reliable from a release scheduling point of view than before. Realistically, though, given our limited resources it has greatly increased our ability to push through incremental point-point releases of the core in reasonable time. Once we finish our big 5.2 push I think we'll be on track to push forward with a more agressive release schedule (many changes have been accumulating in what will be 5.2 for a year now, so testing/fixing will be a bigger chore, we hope to avoid such massive-scale changes between releases in the future).

As Jeff says, we certainly don't have the resources to synch .LRN packages releases at the same time. While all packages are in our CVS tree, and while many are shared (forums, etc), their are substantial packages which, as Jeff says, are of NO USE outside the .LRN environment and the consortium MUST be responsible for maintenance. Those members of our community who, like Jeff, have little interest in selling to the academic e-learning market have no motivation to fix packages like LORS.

On the other hand, of course, .LRN benefits from the fact that many of the packages (forums, calendar, etc) are of direct use outside the .LRN marketplace and our community will continue to enhance/fix them whether or not the .LRN consortium is involved.

I'm going to split my response into a couple of posts to keep things manageable...

>>As Jeff says, we certainly don't have the resources to synch 
>>.LRN packages releases at the same time. While all packages 
>>are in our CVS tree, and while many are shared (forums,
>>etc), their are substantial packages which, as Jeff says,
>>are of NO USE outside the .LRN environment and the 
>>consortium MUST be responsible for maintenance. Those 
>>members of our community who, like Jeff, have little 
>>interest in selling to the academic e-learning market have 
>>no motivation to fix packages like LORS.

That's certainly true - the set of people focusing on the core don't have the time to do all the packages.

But I think the process should be the same. The process around maintaining the forums package should be the same as the process around maintaining the forums package. It should all go under the "how OpenACS packages are done. Not as two separate things.

I'll give you a concrete example:

From the OpenACS process viewpoint, we look at packages from a maturity level. There are certain criteria for each maturity level and a package is labeled appropriately.

From a .LRN viewpoint, there is a concept called ".LRN certified". Now, ".LRN certified" makes great sense from a branding perspective.

From a process perpective - it should be 100% aligned with what OpenACS is doing. ".LRN certified" would signify a certain maturity level and .LRN would focus on maturity levels and working with the OpenACS structure. Instead of .LRN recreating essentially the same process on its own, it would work the process as it already exists in OpenACS.

Carl and others, My post was Socratic because I wanted to get a feeling for what others thought in the community. The consensus, with which I wholeheartedly agree, is that there should be a single process for releases, installations, etc.

If we continue to distinguish between OpenACS and .LRN, I would like the community to agree to the following:

.LRN should not be viewed as something built on top of OpenACS. Instead, .LRN should be a subset of OpenACS. I realize that this is currently not the case, but we should move quickly in this direction.

Secondly, I would like to gain acceptance within the community on how to demarcate .LRN from OpenACS. The current way of driving the distinction is to say something like: "it's the OpenACS-based application for eLearning". I would like to get away from this way of thinking. .LRN should become the OpenACS core + any component "certified" by the community as enterprise class and enterprise quality, irrespective of its use. If the Events module or Project module become enterprise ready, then we should designate theme as .LRN and make it available as part of the .LRN release.

Thirdly, .LRN consortium should become a funding arm for ongoing OpenACS infrastructure enhancements. But if that's going to be the case we need to encourage all OpenACS users to join the consortium, whether or not they use .LRN.

This means that statements such as the following would soon be non sequitir: "We use OpenACS, not .LRN". I am proposing a re-think of OpenACS / .LRN relationship. Every user of OpenACS is ipso facto a .LRN user and should join the consortium. Again, .LRN would be a subset of OpenACS components that meet or exceed an enterprise quality threshold.

Al, you're trying to make the relationship between the two entities something that just doesn't resemble reality.

YES, we've moved the .LRN-specific code base into our CVS tree.

YES, we're doing what we can to merge code to avoid duplication of error, code drift that would kill .LRN's ability to run on our core, etc etc.

But the .LRN configuration is still uniquely matched to the academic environment

And I just don't see the NEED to intermingle our identitities. Has Zope been hurt by the rise of the popular CMS application built upon it, Plone? Hardly. Just the opposite.

Branding .LRN as a vertical application built of OpenACS components with some "glue" helps legitimatize OpenACS as a development platform for the building of vertical applications.

We should, and I am quite sure will, maintain the distinction.

And you should take care with your posts, Socratic or otherwise. What if a University CIO, sitting on the fence regarding giving .LRN a fair hearing, Google's '.LRN" and hits your post on the front page of the search results. Now, that's stellar marketing - "should we disolve the .LRN consortium". If that's all they see, what the hell do you think THEY'LL think?

Doesn't .LRN represent the effort of a specific group users? Shouldn't the consortium do everything in their power to identify, coordinated and establish the needs of users? Shouldn't whatever the UAB comes up with have the highest priority? What is needed to make sure this actually and consistently happens? I'ld say be a user (and manager) and have the TAB worry about the implementation. Dissolve the .LRN consortium if there are no users. To coordinate efforts around LORS is important but how would the users translate this need? How to fullfil the needs of the users is what the consortium should be after, IMO.

Listen to how Bruce talks ( https://openacs.org/forums/message-view?message_id=273318 ) and write the specs along the lines of http://www.joelonsoftware.com/articles/fog0000000036.html
( http://discuss.joelonsoftware.com/default.asp?joel.3.88829.23
http://discuss.joelonsoftware.com/default.asp?joel.3.48094.10
)

One of the needs may be to have bug-"free" software. This could eventually translate into ".LRN certified without bugs" or assigning a "24-hour bug-master" or something like that.

All in all, gather the academic users (possibly in a private forum like Sakai does; if only for the "googling side-effect"), make them complain AND applaud, make the roadmap and define the process how goals can be reached. The goal of .LRN would be to create happy users, not flawless software. Support the users is my gut feeling.