Forum OpenACS Q&A: dotLRN Governace

Collapse
1: dotLRN Governace
Posted by Alfred Essa on 10/18/01 05:34 AM
We need to think about governance and participation for the dotLRN
project. I invite your ideas. We want to begin by compiling a list of
institutional participants. If your company, organization, or
institution wishes to participate in the dotLearn project, let me
know and we will list you on the web site. The only criterion for
being on the list is that your organization is committed to using,
developing, or furthering the platform in some way. At some point, we
will try to raise additional funds for the project and having a
participant list will be very important. Individuals will participate
by being members of various teams (functional, technical,
marketing).. More to follow..
Collapse
2: Response to dotLRN Governace (response to 1)
Posted by Jun Yamog on 10/19/01 07:53 AM
Can you tell me where can I see more about dotLRN project?  So far I know its being done by Openforce and I have seen it a lot.  Thanks.
Collapse
3: Response to dotLRN Governace (response to 1)
Posted by Michael Williams on 10/23/01 03:29 AM
Provided dotLRN can be adapted to work in the k12 environment Haywood County Schools will use and develop. Based on what I have seen of OpenACES I believe that it can be adapted and used to provide much needed parent, teacher and student interaction.
Collapse
4: Response to dotLRN Governace (response to 1)
Posted by Don Baccus on 10/23/01 06:06 AM
From the technical side it is a port of the 3.4 ACES project to the [Open]ACS4.x platform.  I put "Open" in brackets because the work mostly  involves moving to the acs_objects paradigm and using subsiting and other new tools to implement the partitioning of the main site that's needed (i.e. each class will have its own subsite rather than each being built on the user group facility).

So the work is mostly adapting aD work from a 3.x platform to a 4.x platform.  Yet I don't want to belittle the OpenACS component - there will be a new portals package built upon the acs-service-contract model that will yield entities that can be utilized by plenty of other  clients (including vanilla .adp pages - portlet use won't be confined to the portals sphere, as portlets will fulfill a general contract that can be request by a variety of clients, including the new portals package).

I think folks will have to lay off and wait for another month or so.  I'm not speaking as an insider. entirely - obviously I have input into overall OpenACS design issues but this is a contract with OpenForce and Sloan (though I'm sorta a subcontractor - but only "sorta").  OpenForce is doing their best to merge client needs with the general applicability that folks want to see in OpenACS 4.  We - meaning the OpenACS community and Sloan/MIT - share a common vision in wanting the resulting code base to be widely used and of course entirely Open Source (though Sloan/MIT themselves use Oracle).  No need to worry on that front, OK?  Clearly our community can change the result that's released in public if certain aspects that Sloan asks for seem "wrong"  to us.  Of course, Sloan's trying to minimize the transition effort for their current ACES users (i.e. all of Sloan) so they'll be forgiven if certain UI, etc, aspects get copied that don't seem optimimum.  And ... they're open to change long-term, in my experience, having worked on SloanSpace before.

So ... I view this as being very much a collaborative experience.  Sloan/MIT will hold things under wraps in the near term because of tight deadlines (they expect to roll this out as a replacement for next semester, and that includes moving over all data, i.e. bboards, calendars, documents etc).  I expect them to be a source of new ideas for improving their site - in ways that will impact everyone positively - in the future.  Certainly that's been my experience in the past, dealing with them.  They're not the only folks on the planet, for instance, that want the Calendar package to generate iCalendar files so Outlook/KOrganizer/Enlightenment etc can synch with the website!

Collapse
5: Interfacing with .LRN (response to 1)
Posted by Radam Batnag on 10/23/01 11:30 AM

We at Net Effect (Phils.) would like to join the project. We provide IT services to high schools (I think the equivalent US term is k12 schools?) and non-government organizations. Our large software development department (composed of me & myself) would try to be of help in the technical team.

Don, Al, I understand that the project is still under wraps because of the tight deadlines, but I would like to clarify some things about the direction of dotLRN.

Our clients are mostly high schools, and on the top of their priorities are (1) how to manage their teachers, and (2) how to help their teachers manage their students, and they put more importance (and more money) on these than on helping their students collaborate with each other, or on helping their teachers collaborate with each other. As a result, they contract us to work on systems like grading systems, online exam management, lesson plan management, classroom management (room assignments, seat plan, etc.) library management systems, and other systems that have more to do with management than with community and collaboration. You may find this outlook of our clients draconian, and we would really like to change that, but changes like these could take years, and we need cash now. :)

Considering the outlook of our clients, the nature of OpenACS which is a collaboration system, and my hunch that dotLRN will be primarily a system for collaborative learning, and only secondly for school management, we (Net Effect) have decided to focus work on the "management" modules and rely on dotLRN for the collaborative learning part.

1. Can we request a list of the modules that will, and will not be included in dotLRN? This way I can avoid doing duplicate work that will eventually be discarded when I find out that dotLRN has a superior version of the same modules.

2. There are issues that are in common in systems that have anything to do with schools, students, teachers, and classes. Issues like - how do you specify who is enrolled in what class? how do you specify who teaches what class? what class occupies what room at what day-of-week/time-of-day? I've already done a primitive enrollment system that does this, but I'd prefer to work on systems/modules that build on top of dotLRN than to work on systems that build on top of my primitive enrollment system. How do I write a module that interfaces with dotLRN? This early, can you share the data model?

Collapse
6: Response to dotLRN Governace (response to 1)
Posted by Allan Regenbaum on 03/08/02 05:33 AM
Radam... have you made any progress in this regard .. I want to implement this at an elementary school...
Collapse
7: Response to dotLRN Governace (response to 1)
Posted by Radam Batnag on 03/11/02 03:32 AM
Allan,

I've built a quickie system using OpenACS 3.2.5. It implements enrollment, lesson plan and student projects storage (using a modified UI of the 3.2.5 new file storage module), seat plan and attendance.
It's a simple modification of the UI and some extension of the data model. We have deployed this to one high school with 1800 students and 100 workstations.

I'm currently working on a new version using OpenACS 4. Like the 3.x version, it's a simple customization of the OpenACS 4 UI and some extensions to the data model to implement enrollment, grades, seat plan, attendance, school calendar, and class calendar.

Where will you be deploying the system? US?

Collapse
8: Response to dotLRN Governace (response to 1)
Posted by Dave Bauer on 03/23/02 01:53 AM
Was a list of contributors ever compiled? Many organizations posted on these bboards that they would like to be involved and contribute to dotLRN. This was originally posted back in October. Has there been any progress?
Collapse
9: Response to dotLRN Governace (response to 1)
Posted by Ben Adida on 03/23/02 03:39 AM
Dave,

The dotLRN project is nearing a pre-alpha release. We have a
date: Friday, March 29th (next week). We apologize for the delay,
but we've learned a lot about end-user open-source application
development in the process, and we're confident that with a solid
architecture beginning, contribution to dotLRN will be that much
easier.

Collapse
10: Response to dotLRN Governace (response to 1)
Posted by Adam Farkas on 03/23/02 04:42 PM
Awesome news, ben! Can't wait to see this thing. (We, like many folks, may have a need to build on it.)

Most of us are in the dark about the actual functionality, etc. Could you give us a little compare & contrast as to how it's different from Yahoo! Courses (http://courses.yahoo.com)

I think by comparing it to something that we all know we'll get a better grasp of its scope.

should be cool. thanks for the hard work.

Collapse
11: Response to dotLRN Governace (response to 1)
Posted by David Kuczek on 03/24/02 12:28 PM
Pilot Web Sites Built

The OCW Transition Team has built 20 pilot course web sites for internal testing at MIT this spring. Several of these sites will be the primary online presence for their respective courses this semester, providing an opportunity for user testing and evaluation of the sites' structure and design.

-- http://web.mit.edu/ocw/index.html

Is there any technical connection between OCW and dotLRN?

Collapse
12: Response to dotLRN Governace (response to 1)
Posted by Radam Batnag on 03/25/02 10:16 AM
Ben,

Al Essa's original post on dotLRN was dated October 2001, and since then, a lot of people, including me, have pressed you to release details on the dotLRN project. Yet, you didn't release any. We kept badgering you to release details. I pleaded for even just a peek at the data model. Still, no response.

Thanks for the wise move!

If you have released early, people like me would have built on top of what you've released. I understand now that you don't want this early in the development phase. An early release, and people building on top of the early release, will have the ugly consequence of locking the developers to the early design and APIs. You wouldn't be able to make radical changes without pissing off people who have built on top of what you have released.

Again, thanks for your great efforts, and for keeping mum on the dotLRN details. We await the alpha eagerly.

P.S. Now that dotLRN alpha is imminent, maybe we can proceed with Al Essa's original proposals for the governance of the project?

Collapse
13: Response to dotLRN Governace (response to 1)
Posted by Ben Adida on 03/25/02 02:15 PM
OCW is its own project, independent from dotLRN. OCW is a
content delivery effort, not a collaboration-oriented one.

With regards to our releasing details about dotLRN: I have put
significant thought into how OpenForce can open up the
codebase without creating unhealthy expectations (product
readiness and backwards compatibility) before it's really
possible. I'm beginning to come to the conclusion that Eric
Raymond's "release early, release often" concept is deeply
flawed for certain categories of software. And yes, I have certainly
repeated the Raymond mantra many times myself in the past,
so I'm not blaming anyone for saying it now. I just believe that we
(OpenForce) are learning something new about open-source
development through dotLRN.

No, I do not think that we acted in a perfect way, because we
could have at least released design documents earlier (as Don
mentioned in another thread). But I do think there are very good
reasons why releasing code before this week would have been
premature and even risky to the success of the dotLRN effort as
a whole.

A few points to conclude: 1) Code is coming shortly, 2) There will
be means of contributing made available progressively, but
contribution *is* most definitely encouraged, 3) I'll be writing up
my thoughts soon on the open-source development process as
it applies to dotLRN,

Collapse
14: Response to dotLRN Governace (response to 1)
Posted by David Geilhufe on 03/25/02 11:10 PM
Ben,

I'll be interested to hear your thoughts on open source development for dotLRN.

In following this project, I am struck by how many different things people are talking about. It seems there are three things that are really important.

1. dotLRN will create changes in OACS. Those changes in either existing pacakges or creation of new packages for OACS need to have a path into the main OACS distribution.
2. dotLRN will have community participation in the coding of an application delivered to client.
3. dotLRN will provide and application and code base that others might want to build on for their own purposes.

In the case of number 1, I totally buy the "release it when it is ready" concept. No need to incorporate elements of dotLRN into the OACS release until those elements are tested and client ready. At the same time, releasing information on those elements could be incredibly useful to the community... someone is working on a revised bboard, but has no idea if the dotLRN bboard would meet their needs. So documentation only seems logical.

In the case of number 2, dotLRN is not really an open source project... it is a a project where a vendor (OF) is using an open source toolkit to produce a client work product for MIT. Too my mind, there is no place for open, rolicking community participation in that process (sorry, too many years of consulting for corporate clients in my background). As a moral issue, of course, as soon as the thing is delivered to client, it should be released back into the community.

In the case of number 3, it seems that there is no problem releasing the code and documentation. People will go on their merry way with no effect on the client project.

Now of course, this analysis is basically the opposite of what Al Essa laid out in the first post of this thread, but it is a very appropriate way to run a client project.

And finally, the "release early, release often" mantra really only works for open source software development... development where multiple companies and individuals are working together on a project. Where all parties are making a contribution and taking the code in the direction of their collective enlightened self interest.

Since that is not the case here, it seems logical to wait until the client deliverable has been finished, then release it to the community, then begin building an open source development community around it.

And since OACS is already such a community, it seems the only action required on the part of Open Force is to release the software back into the community after the client deliverable has been completed.

Now, if part of the client deliverable is to build an open source community around the dotLRN software, this logic still holds up. The important thing is to finish the client deliverable, release it to the community and start building the community around the folks that come out of the woodwork and are recruited into the community.

Collapse
15: Response to dotLRN Governace (response to 1)
Posted by Ben Adida on 03/25/02 11:59 PM
David,

Great questions.

In our work on dotLRN, we have encountered *numerous*
limitations and missing features in OpenACS. All the changes
we've made there are already checked into the OpenACS tree,
and we've made them by doing our very best to maintain
compatibility. This includes mostly refactoring some APIs,
adding new APIs to complete features (think of permission
granting, site nodes manipulations, etc...). We've also gone in
and fixed a number of packages, like FAQ, survey, calendar, and
more. All of these changes were rolled into the OpenACS tree
immediately.

Now, there is at least one example of a package (bboard) where
we have forked from the OpenACS tree. This is because Sloan
has very specific needs in terms of discussion forums. *
However*, this is not something that impacts dotLRN, because
dotLRN can use any bboard system. In fact, our dotlrn-bboard
module allows you to use either the Sloan Bboard, or the
existing OpenACS bboard.

What we're trying to do is an optimal combination of points 2 and
3. We spent some time thinking about the core architecture with
respect to our client's needs. But now that the core architecture
is really in good shape, we can start releasing this code and
work on specific client modules that will not affect the way the
core dotLRN platform functions. There are great synergies here
(oh boy, I said "synergy"), and we want to make sure Sloan *and*
the community benefit. This is not just our goal, by the way.
Sloan has expressed great interest in building the dotLRN
community.

I disagree with you on one thing: our job is not as simple as
"releasing the software back into the community." There is a
clear issue of dotLRN governance, how it evolves, how we
involve the community and yet provide a useful direction. It is one
issue which Sloan and OpenForce will address in the very near
future. But it's really not simple, and I don't think many open-
source projects with this type of audience have done this
successfully yet.