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

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?

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.

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(https://openacs.org/projects/dotlrn/roadmap) - 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.

"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 :)

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.

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.

Michael

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.

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.