Forum .LRN Q&A: .LRN as a distribution of OpenACS

Posted by Alfred Essa on
There is considerable confusion still about how we should be thinking of the relationship of .LRN and OACS. It's important that we begin to reach agreement as we pick up the pace with .LRN marketing.

In our discussions the consensus seems to be that .LRN really is OACS and that we should try to eliminate any code divergences between the two. For example, the .LRN portal system shold be part of OpenACS. Correspondingly, we should make similar simplification in our governance. Is it necessary, for example, to even have a separate technical advisory board for .LRN?

One way to characterize .LRN would be to see it as a "distribution" of OpenACS, much like Debian is a distribution of Gnu-Linux. One of the responsibilities of the .LRN consortium would be to maintain the distribution. The .LRN distribution would try to provide a level of quality assurance, documentation, upgrade path for previous releases.

Does this notion make sense?

Posted by Nima Mazloumi on
Dear Al,

I think this really does. I even see the i18n terms for dotLRN as an ontology for learning spaces thus we could have different one for companies, communities...

The less code divergence we have and the more customizing on the distribution level the better for all of us since ressources are very valuable and redundancy a killer for open source communities.

What do you think?

Posted by Joel Aufrecht on
"Does this notion make sense?"


Posted by Malte Sussdorff on
It makes a lot of sense, though til now I've always been talking about a vertical application instead of a distribution. I think it depends whom you talk to.
Posted by Tilmann Singer on
I would rather call it an application or a set of applications running on top of OpenACS, not a 'distribution' of OpenACS - it is definitely not what Debian is related to Linux for example.
Posted by Tracy Adams on
When I took the role of release manager of .LRN, the first obvious  question was "what it my role".  The role of release manager of .LRN  wasn't as obvious as release manager of OpenACS.  After watching a bit, I noticed there was confusion about what the .LRN release was and how it related to OpenACS.  I brought up the question last Thursday at the .LRN  weekly chat, specifically about the .LRN TAB.  This led to more discussion and Al's post, which will hopefully let us clarify things.

This posts outlines some of the documentation and processes that may  give the impression that .LRN is a separate development project as opposed to a distribution of OpenACS.  If we were to truly run as a distribution of OpenACS, we'd work to remove or reduce these things.

1) .LRN RoadMa( - Notice  that many of the packages are OpenACS. As a TECHNICAL and PROJECT MANAGEMENT page, this gives the impression that the .LRN has an independent roadmap of the basic platform.  What we are really seeing here is a proposed OpenACS roadmap. It has served us well, but it also presents confusion about what OpenACS and .LRN.  I propose
removing this page from the .LRN site and transferring it to OpenACS should they want to make use to it.

2) Separate Technical Committees - If .LRN is a distribution of OpenACS,  why is there a separate technical committee?  For example, when the .LRN initiative wanted to add internationalization, they worked with OpenACS and the OCT, not through the .LRN tab.  There is a desire for the .LRN members to be informed about technical developments and also to help ensure that OpenACS will meet the needs of universities.  However, it is clear that all the technical action takes place on as part of the OCT.  In practicality, this is how it has been working anyway. 3 of the members of the OpenACS OCT are on the .LRN Tab.  The proposal is to do away with the .LRN Tab because, again, it gives the confusing impression that .LRN is independently making technical decisions.

3) There are code differences between OpenACS and .LRN.  Although most of .LRN is core OpenACS or packages, there are differences, particularly in the portal and the master-template. It has gotten to the point that .LRN and
OpenACS can't coexist and that developers have to be careful when  developing OpenACS so they don't break .LRN.  These are historical and there is strong agreement that the differences should be removed.  Only question is getting the development effort.

4) Management of bugs.  After the release of OpenACS 5.0, we went through and labeled the bugs that were most important for .LRN and labeled them as "fix for .LRN 2.0.1" in the bug tracker.  The OpenACS community focused on  identifying bugs for OpenACS.  As a result, the .LRN bugs are kind of "lost" in the confusion between the 2 processes.  Some of these bugs are in the  OpenACS code and some are in the .LRN part of the code (the problem being the separation mentioned in #3.

Posted by Janine Ohmer on
If the TAB goes away, then who looks after the technical interests of the packages that make up dotLRN?  I'm not sure that those interests are significant enough to warrant a whole technical board, but perhaps there should be an official .LRN seat on the OCT?
Posted by Don Baccus on
"Vertical Application" captures the difference much better than "distribution", as is mentioned above.  .LRN really does implement a very specific, very stereotyped application and this goes beyond distribution.

But a "vertical application" isn't necessarily going to be built only from standard supported OpenACS packages in the future (i.e. supported in our CVS structure).

So I'm not quite sure how to name the beast in a way that makes the most sense.  Only that "distribution" ain't the right word :)

Posted by Rafael Calvo on
I agree with Don, "distribution" is not the right word. Managers hate having to chose between Debian, RH and other flavours...

I would say "application" but they could get confused with real openacs apps. How about "product" or "project"

Posted by John Norman on
I am not too worried about what dotLRN as it is today is called, but I would like to see the community move toward a situation where dotLRN is more like a configuration/template option for OpenACS. i.e. we would be running OpenACS, but with certain options on or off.

Even more exciting would be an enterprise application for a University where we can use OpenACS-like communities for; the Basketball Club with ETP for the Basketball Club website, a community for Chemistry Tutors developing a new course, a course alumni community with e-commerce for an online shop/contribution/booking service, or a secure course area with extra 'tools' available for supporting an online course.

Posted by xx xx on
- .LRN should be an openACS "Configuration". I don't like "Vertical application", because it needs a clear definition.
- I consider openACS core to be groupware
- .LRN would be groupware for schools/universities.

As I see it, a .LRN release would be an installation script, including:
- an upgrade script from the latest openACS (core) release (including new bugfixes)
- a subset of packages that .LRN considers "core".

.LRN is (will be) openACS' major real life example, which is extremely important for marketing.
IMVHO, openACS should adopt all groupware specific features from .LRN including the portal system (the latter probably optional) removing all code differences.
Shouldn't openACS be the "Infrastructure" of the dotLRN roadmap ( ? Is there a reason it cannot be or should not be?

OCT would govern all groupware specific stuff.
.LRN TAB must govern specific .LRN needs in packages, groupware and bugfixing (since .WRK TAB may want different things one day...).

Posted by Michael Hebgen on
Dear Al and all others,

for me is .LRN something like a package of OpenACS, but not
a simple package like "Wimpy Point", more a package of OACS
packages including some specialities to support Learning.
By the way we need much more than just a flavour "groupware
for universities/schools".

This discussion reminds me on complex systems (e.g.
mainframe operating systems) where we would have named
.LRN to be a "subsystem" with the attributes

- use as much of the underlying system (OACS) as possible -
  one portal system for all e.g. or easy integration of
  existing OACS packages into .LRN etc.
- special interfaces to OACS where necessary, external
  authentication e.g.
- special integration to OACS where necessary, for example
  internationalization needs different coding rules to
  enable an OACS package to be included into .LRN

The recent .LRN development - internationalization and
external authentication - was initiated through and by
the .LRN community, but has greatly affected OACS.

So finally naming

    .LRN a (or better THE) subsystem of OACS

would in my limited knowledge of the english language
describe at best the situation and intentions.


Posted by Don Baccus on
I use the term "vertical application" because
  • It has an existing dictionary definition
  • That definition seems to fit
Here's a definition:
vertical application

(application, jargon) An application program supporting one specific industry process, e.g. for e-commerce purchasing applications, the entire distribution process including order entry, shipping, and customer service.

I'm working on making the portal system work standalone in OpenACS. Actually, that works at the moment, I'm working on making the portal system a better written piece of software ...
Posted by Malte Sussdorff on
From a strictly marketing point of view, we could call it "vertical solution" or even "industry solution", terms which are used on a regular basis in the IT consulting industry
(SAP names their specific setups of R3 industry solution). Also, in contrast to application (which focuses on the product) the term "solution" implies that it can actually help.
Posted by xx xx on
OK, I understand the "vertical" part better now.
But what part of "vertical" is and remains openACS? I'ld really like to know in terms of:
  • application (solution/functionality)
  • code
Is this something OCT and .LRN TAB (need to) know?

Semantics are important, given the planned world-wide release . It reminds me of the discussion around writing specs. Should technical or functional jargon be used?

Who are the ones to convince if one wants implement .LRN? I think we should use the jargon that decisionmakers use.

In a project one would probably create one or more "focusgroup meetings with 10-12 decisionmakers" to see what they report back if we try to explain .LRN to them ( including its relationship to openACS and , off topic but important, 450 bugs).

Posted by Malte Sussdorff on
Let's take .LRN vs. OpenACS as an example. OpenACS offers all the functionality of forums, file storage and so on.

.LRN is a prepackaged solution which installs on top of stock OpenACS code pieces and preloads the database to make it easy for an educational environment make best use of OpenACS. This means, you get forums, file-storage and other packages preinstalled, you have the roles set correctly for professors and others, you have custom applets that may be different from the stock ones shipped with the new version of OpenACS.

Other vertical solutions that come into my mind:

.NGO for non profits with intranet functionality and the campaign tools that e.g. Greenpeace is using and building.

.WRK a solution for the office space that Lars described some time ago and is working on. Preinstalled and ready to roll, maybe with it's special setup page to install one or more offices (instead of the normal bootstrap installation that comes with OpenACS)

This is where the vertical comes in. It stretches across all functionality of OpenACS, but exposes certain parts in a special way, predefined and packaged towards a certain user group.

For the moment though we are not even close to a state where .LRN is "only" a vertical solution due to the magnitude of changes and additional packages that it incorporates. But the goal (at least to my understanding) has been to create a functional layer on top of OpenACS that makes up .LRN.