Forum OpenACS Q&A: Why we should dissolve the .LRN consortium
I think we need to view ourselves as a single project, instead of OpenACS and .LRN. Having two governances, two releases, two installers, two communities, two brands, etc. is not workable. We should be a single project, a single community, and a single brand.
Let me put forward a heretical proposition. Let us dissolve the .LRN consortium and create a single community, a single project, and a single governance. Perhaps we re-brand OpenACS and call it something else, or leave the name it is. The power of OpenACS is that it goes beyond just "learning" or "e-learning". Ultimately, I don't care what we call the project or community but it should be one entity with a single focus, direction, and discipline.
What do you think? Let's not be afraid to think outside the box.
.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).
>I think we need to view ourselves as a single project, instead of OpenACS and .LRN. Having two governances, two releases, two installers, two communities, two brands, etc. is not workable. We should be a single project, a single community, and a single brand.
* Yes, we should view the software development as a single project - OpenACS.
* We should have one technical leadership team - the OpenACS Core Team.
* We should have one release management process. Right now, we have it that the OpenACS focuses on core and the .LRN focueses on some of the packages. Everything should be under OpenACS release management.
.LRN does have value as a brand. The .LRN community of educational institutions focusing how to use this software in education does have value.
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".
One thing Al said I disagree with: "Ultimately, I don't care what we call the project or community but it should be one entity with a single focus, direction, and discipline."
I think we are largely "one community" now but I don't think is that it's reasonable to say that we are going to have "one direction". As it stands we (Xarg) don't use .LRN now and for the kinds of websites we build we are not likely to in the future. The fraction of the dotlrn code we have interest in using has declined a lot over time, primarily because we don't have need of things like LORS or other IMS/education stuff.
Also on release management -- core and critical packages (forums, file-storage, etc) is large enough and hard enough to QA/release with the resources we have now, I don't see how we can sustain monolithic releases also I think the discussion of what needs to be done for release management is important but pretty orthogonal to the organisational structure/branding of OpenACS/.LRN.
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...
Much better for the project as a whole, IMO, is if OpenACS becomes known as the base technology for a suite of successful vertical applications ... .LRN and (gee it would be nice :) .WRK being our two existing examples. Alternative configurations of OpenACS ... sure ... that's the whole point. We want to continue to push forth to where alternative configurations packaged nicely, perhaps integrated with a slick install process, are the norm for people looking for canned solutions that only need theming (by the upcoming theme-manager) and perhaps minor customization to meet their needs.
In fact Jeff has made some considerable enhancements to the install.xml customization process I wrote to make possible the automated installation of .LRN as simply a configuration of OpenACS. He's done this because his client projects are installed/delivered using this mechanism. I suspect the value of this has been somewhat hidden due to all of our angst regarding the initial install headaches involving AOLserver, PG, Tcl-threaded etc etc.
>>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.
Also ... TAB quietly drifted into the sunset as we began centralizing tech decisions into the elected OCT. I think this is right, and perhaps should be explicitly acknowledged. TAB, today, only informally acts as a sounding board for tech evaluation of microgrants (which by their nature have to be evaluated in the context of .LRN consortium funding priority).
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 wrote:I'm sorry but I'm stupid and lazy and I can't resist the temptation to ask: *Why would one want to that?* The part I don't understand is why should this be the case and not vice versa which makes more sense to me (at least), i.e. .LRN would be "certified" as *one* (not "THE") enterprise class and enterprise quality e-learning solution built on top of OpenACS, i.e. a vertical application.
> .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.
If I understood correctly, Al claims that .LRN is a subset of OpenACS (the project or the codebase (???)) and at the same time Al also claims that it's the superset of the OpenACS core + "certified" packages, however, still "a subset of OpenACS components that meet or exceed an enterprise quality threshold" irrespective of their use again according to Al. I'm confused!..
For the time being, I'll avoid to comment on the second part of Al's last message since I'm not sure I understood exactly what it says/means.
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?
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
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.
Like others, I disagree with your statement:
".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."
Don gave the example of PLone/Zope. You can also think about our competitors: BEA/WebCT (on WebCT vista). I think the model of having a vertical application works pretty well, and is easily understood by CIOs.
Regarding marketing and project names I wouldn't mind changing the name of OpenACS together with the dog. Every single marketing type person (and commons as well) have said that the name is not clear, not catchy, etc.
I have noticed quite a lot of activity recently, much more than I have seen in the last few months. This might be a risk or an opportunity to make big changes. Part of it might be due to the humungus thread started by Al. Those titles he uses call everyones attention!. Regretably I agree with Don and it is risky if some external person reads it... worse if they know who is Al.