Forum OpenACS Q&A: Summary of the Sloan - Berklee dotLRN meeting

.LRN will benefit most from the difference in our projects.

• Sloan is using Oracle, Berklee is using Postgres.
• Berklee's Phase I is supporting distance learning and creating a tool for structured course delivery. Sloan’s Phase I is supporting a brick-and-mortar university with online community tools.

We both want to keep the general OpenACS community informed about specific areas where Sloan and Berklee will be focusing in the next few months.

• Berklee and Sloan will be working together expanding the Survey Package.
• Berklee is developing a basic LMS capability to deliver existing HTML course content.
• Berklee is currently evaluating chat solutions.
• Sloan will be creating a Photo Book Package to display and manage students' photos and profile info.
• Both groups will be doing extensive customization as well as working on general .LRN UI and functionality.

Sloan: Caroline Meeks cmeeks@mit.edu
Berklee: Michael T. Serio - mserio@berklee.edu

Dear Don,

I'm very sorry you feel you have not been consulted.  I was under the impression that Sloan was contracting you do the very first non-Open Force .LRN package (Homework Drop-Box) specifically so you could use it to model best practices.  My understanding was that you had already received the spec. Sounds like there has been some confusion.  Please call me voice tomorrow.

I think I do speak for both institutions and the programmers when I say we are 100% behind and wish to be a part of OpenACS, however, the "We" in the above post was not ".LRN", but the two specific teams of developers who are using .LRN to create specific client sites, with concrete defined requirements,  and very strict deadlines. If you read this announcement closely, you'll notice that despite the fact we are less the 2 miles apart, both doing web sites that support classes for universities, the only piece we found to really collaborate on in the short term is Survey.  Basically we are at the point of saying. "We both need survey and neither team has started on it yet."  "We" are not the OpenACS community. "We" are not .LRN. "We" are not ArsDigita.  "We" are two separate teams focused on our deadlines and deliverables.

After we meet these deadlines, these two specific websites will "gift" this code back to .LRN and then we as individuals and community members will certainly hope to work with you and the rest of the community in building and improving .LRN and OpenACS.

When I was at ArsDigita, I tried and completely failed to explain to my management that what we had really built for Sloan was an intranet.  As programmers it's obvious to us that these packages have extensive general usefulness across industries.  I learned the hard way that this is not obvious to business people.  They think in terms of Industries and Sectors.

The way I see it is .LRN is a "brand". It is a distinction we can make while marketing to help us communicate with educational customers that we understand their problem and have a proven tool to help them solve it.  From a technical point of view it is my individual opinion that it is best for all of us for .LRN and OpenACS to be as close as possible.

Again, these are my personal opinions and vision, they do not necessarily reflect Sloan, Berklee, Open Force or .LRN!

I understand the business perspective and also the history of ARSDigita/OpenACS. I truly believe that OpenACS will be a better product eventually due to the work of the S/B teams.

I also completely understand the concerns of Don and the OACS community. Hopefully any core changes you are about to make will be made public before they are committed in stone (of course, you don't have to do that). Then we won't have the reinvent the wheel problem that happens (and happened at AD) frequently when great ideas get implemented by multiple parties independently.

There are certainly some very weak aspects in OACS as inherited by AD, but there are many strengths also and certainly OACS is a much more stable product in the community than it ever was at AD.

I look forward to any enhancements S/B creates and also any new packages. Thanks for keeping us in the loop at all.

These two universities are always at the forefront of technology (MIT) and arts (Berklee), and this represents a great opportunity for the openacs community. If they are successfull the whole opensource community will be successfull.

The OACS community will soon have one of the top Business Schools and one of the top music schools in the world using dotLRN/OACS. We will have the largest enviromental movement in the world (Greenpeace) using OACS and we have companies like Siemens that use ACS and could eventually use OACS as well. These are great news!

I believe the community is very aware and happy for this.

I also agree with Caroline and we must think of dotLRN as a "brand" of OACS. It is the killer application that the project needs and will help develop.

On the other hand, the developers I have talked with are trying to find ways of collaborating with openforce, or at least of not reinventing the wheel. Since OACS is very modular the best way I found of doing this is building things that other people is not (previous consultation with Don and Ben). I think that is a good way to work for all. If people working in openforce and Berklee tell Don (or post it in the bboard) what they are working on, we can try not to overlap.

Finally, there are other universities that would like to be more involved in the dotLRN project, and would be able to add value to it. Al and Caroline had planned to be more open about the dotLRN governance, but I haven't heard much about it. How can other universities participate more in the "strategy" aspect of the "brand"? I am consciously trying to separate this from the purely Software engineering aspects, since I don't think that IMS compliance, learning objects, etc,.. are issues that the OACS cares much about. How can we collaborate so other universities start using it?

One really import point for us in Europe is the support for multiple languages. Please note that most (if not all) major commercial learn platforms made the mistake of not being localizable from the start, and are paying for this now (figuratively and literally). I just wanted to mention this, because I doubt there are many foreign language courses at Sloan or Berklee, internationalization is easy to forget about when on a tight schedule, and working on it after the fact is a lot harder than when it is considered from the start (not to mention that making something support multiple languages at a later stage requires more coordination and communication than if it is done from the start).

This is important.

Finding out that OpenACS is the platform Greenpeace has chosen, eases my multilingual concerns on the OpenACS side (although it does not eliminate them). I just hope that the multilingual features of OpenACS and dotLRN will "dovetail" as so elegantly stated by Don. Obviously, the best solution would be one that is independent of dotLRN and built into OpenACS, making multilingual support a snap.

Can somebody that knows both systems and has experience in internationalization please comment on this? Who is working on this?

- Survey Builder:

https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0002Qz

- Chat:

The chat should be an applet and not a standalone program that users would have to download and install...

dotLRN will not run on the OpenACS 4.5 release that will be issued in the next week or so.  I know that Sloan's goal is to release dotLRN "sometime" (when?).  I assume that it would be in Sloan's best interest if dotLRN, when released, will run atop a named OpenACS 4 release.  "Grab the nightly tarball built on July 4th, 2002" probably doesn't cut it as a named release.  Just seems too unprofessional ...

Sloan could cut their own release of OpenACS 4 and bundle it together with dotLRN.  That risks a unintentional fork in the codebase, though, due to the temptation to fix bugs and all that.  Note that ACES was a fork of ACS 3.x and the codebase wasn't 100% merged until recently, by ex-aDer and OpenACS community member Malte Sussedorf.

Now ... if Sloan does see value in releasing dotLRN to work on a named release ("4.6" for convenience), how does Sloan see that becoming a reality unless Sloan actively coordinates with the community?

In particular with me, the person the community expects to more or less coordinate production of that release?

Ben has started talking to me about this issue (I told him we should start floating 4.6 ideas as soon as I get 4.5 out, for those of you who think we plan to hold this discussion in private).  My impression, though, is that he's doing this on his own initiative.

As part of this, I expect that Ben or someone will inform me of Sloan's planned schedule through alpha, beta and final releases.  I hope that *someone* on the Sloan side - and if Sloan's appointed Ben to do this, fine, but how about saying so explicitly? - will inform me of that schedule so we in the community can decide what a 4.6 release should look like.

Also ... I think it's clear that there are going to be some minimal community expectations for an OpenACS 4.6 that can serve as a named foundation for dotLRN.  While dotLRN proper won't support Postgres right off, if the new portals package is going to be part of OpenACS 4.6 - and that's where it belongs, without doubt - it will have to support both Oracle and Postgres.  Code that doesn't won't make it into an OpenACS 4 release, pure and simple.

So we need a final determination if OF or the community will do that work.  This isn't Sloan's responsibility, but because it impacts "OpenACS 4.6" it has the potential to impact dotLRN's release.

I'm really talking nuts-and-bolts stuff here.  I wonder, for instance, if Caroline was fully aware that dotLRN won't run on OpenACS 4.5?  Being "in the know" at this level would be a consequence of closer coordination between the OpenACS project proper and projects like dotLRN.

They aren't the same project, and shouldn't be.  I'm certainly not lobbying that the OpenACS project, rather than Sloan, drive dotLRN.  Sloan has specific needs that must be met and must have a deployed solution that fits those needs.  Fall Term (Sloan's planned deployment) is just around the corner, in software engineering time.

But Sloan also has a broader vision than internal deployment.  And *that's* where some level of coordination at a nuts-and-bolts level seems very necessary.

OK that's post #1.  I've got one more :)

Finding out that OpenACS is the platform Greenpeace has chosen, eases my multilingual concerns on the OpenACS side (although it does not eliminate them). I just hope that the multilingual features of OpenACS and dotLRN will "dovetail" as so elegantly stated by Don. Obviously, the best solution would be one that is independent of dotLRN and built into OpenACS, making multilingual support a snap.

Can somebody that knows both systems and has experience in internationalization please comment on this? Who is working on this?

I guess I don't understand in what way we haven't done exactly as you suggest about Survey.

We posted our intentions to work on it before we even have a spec written.  The community knows about this project before a single line of code is written, before the requirements are even done and certainly before a contractor is picked.

I've been talking with the Survey Builder group out of UCLA, I've been talking to Ybos, I've been talking to Open Force.  I've emailed my draft, which is hardly a spec at this point, to someone from UMass Donahue who emailed me in response to this post.  I talk frequently to Michael Feldman. I've also gotten really good ideas on this subject in the past from the Berkman Center at Harvard.

The community is being involved before the draft of the spec is even done.  Your posts are not exactly acting as positive reinforcement.  Exactly what more do you want me to do?

I've been talking with the Survey Builder group out of UCLA, I've been talking to Ybos, I've been talking to Open Force. I've emailed my draft, which is hardly a spec at this point, to someone from UMass Donahue who emailed me in response to this post. I talk frequently to Michael Feldman. I've also gotten really good ideas on this subject in the past from the Berkman Center at Harvard.

The community is being involved before the draft of the spec is even done.

Your posts are not exactly acting as positive reinforcement.

Exactly what more do you want me to do?

My stock answer - "I dunno, no one bothers to tell me" - gives folks little satisfaction.

So maybe a commitment to keep the OpenACS Project Leader informed in a broad, general way as to what the future looks like from Sloan's perspective? Not me, personally, but whoever fills that role, which happens to be me at the moment?

From a technical point of view we absolutely have to be sure .LRN and OACS are compatible, hopefully to the point of being almost the same thing. But please be tolerant of the fact that we will be trying to create a separate image that says education. This .LRN centric language will probably get worse not better in the next year or two. This separation does not mean that technically we don't consider ourselves part of the community

So I doubt you're going to see opposition to your efforts to market .LRN as a branded app.

Caroline, Michael, and Al, it might be possible for the Sloan
and Berklee to realize some more synergies with the community
(and make folks on the outside feel more involved and
energized) with a relatively small effort. Here's an example of
how things could go with something like the survey
enhancements:

1. Berklee and Sloan decide they are going to enhance the
   survey package.
2. You spec out your requirements.
3. You do a quick search of the bboards to see what
   conversations have taken place that might be relevent to their
   goals (like
   https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0002Qz&topic_id=11&topic=OpenACS, for example) and incorporate
   any ideas that you like
4. You post a message to bboard saying, "We're going to
   enhance surveys. Here are our high-level functional
   requirements and rough spec. Obviously, we're going to have to
   do this in a way that meets our needs, but before we start
   building, does anybody have any ideas/suggestions/requests for
   us to keep in mind?"
5. You read the suggestions and take the ideas you like.
6. You post a message to the thread saying, "Here's what we've
   decided to do. We'll let you know when we're ready to release the
   code.

If you want to see a good example of this process in action,
then check out this thread:
https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0004HO&topic_id=12&topic=OpenACS%204%2e0%20Design

I think you'd find the return on your investment pretty
substantial. For a couple of hours' worth of effort, you'd get some
good ideas, substantial good will from the community, and very
likely some folks who are willing to enhance what you're building
and return those enhancements to the community. You're not
giving up control of your own process, priorities, and schedule,
and you're not investing a large amount of time in writing up docs
that you wouldn't have to write up anyway. You're asking for input
but you're not promising that you'll do anything unless it meets
your needs. You might get increased email from excited folks
who are eager to get their hands on your code, and you might get
a little grumbling from folks who aren't happy with your
design/feature choices, but you'll probably get that no matter
what you do anyway. Unless I'm missing something, there's
almost no downside.

Just a thought.

A personal heads-up to the OpenACS project manager - me - would be useful. Keep in mind that folks ask me questions. "what's happpening?" "what's the plan?"

My stock answer - "I dunno, no one bothers to tell me" - gives folks little satisfaction.

So maybe a commitment to keep the OpenACS Project Leader informed in a broad, general way as to what the future looks like from Sloan's perspective? Not me, personally, but whoever fills that role, which happens to be me at the moment?

I think this is a wonderful idea Don. People in the educational vertical come to me with the same questions. I had no idea you were doing the globalization work for Greenpeace and I'm very interested.

Why don't we commit to a voice meeting at least once every two weeks, after which we can jointly write minutes to the Bboard, perhaps even starting a few different threads to keep discussions organized.

As other Vertical Apps start to have multiple organizations collaborating, we can include one representative from each vertical in a conference call.

The orginal post was intended to inform the community we were at Step 1.

That's great, then. I look forward to step 4 with great enthusiasm.

Don wrote:

On the other hand, it doesn't have to be me. What we need is a conduit of information who understands both the community here and Sloan's internal needs and workings. I would put Michael Feldstein on the spot but if I do, I may not live to see the morning :) As dotLRN rolls out, usage grows, it learns to speak Postgres ... I think chances are excellent that someone will step forward to take on the role of trying to coordinate OpenACS releases and changes with dotLRN extension needs.

As long as everyone understands that I am *not* an OpenACS project leader and that my understanding of the programming issues are limited at best, I'd be happy to help out in whatever capacity would be useful. Caroline, if you would find it useful to speak with me instead of Don for the updates, then I'd be happy to take responsibility for helping post the minutes to the community and for pinging Don whenever it feels like we're onto an issue that might need his direct attention.

I'm not sure if I'm the right person for the job, but I'm happy to do it to the best of my abilities.

Even the simplest connection between seemingly disparate problem spaces can be difficult for commercial managers to see.

Branding is possibly as important as functioning in the commercial world (well perhaps not that important) and therefore is this a time to suggest a general theme/brand for vertical applications etc..

Seems to me the Sloan folks have the start of a good branding pitch there that could be quite naturally evolved into the overall OACS consciousness (did I just use that word??).

I.e.

dotLRN

dotWRK

dotMRKT

and so on......

Although entirely off this topic, is there any case for essentially packaging OACS distributions in these formss, perhaps with more pre-configuration. In this way we present the same excellent package to a variety of industries whilst seemingly offeringa specific solution...

Simon

a) We have the perfect solution that runs on top of a great web
server you may not have heard of

b) We have a great fully-packaged solution

The answer was (b), even though (a) actually contains (a little)
more technical information. The truth is that many buyers of
polished vertical apps *don't want to have to know what's under
the hood.* They want to know that they can install it and have it
work. They may occasionally want to know about data
interchange standards for integration (usually in XML, at least in
the eLearning world). They very rarely want to know how it works.
The technical stuff scares them. If you can tell them that they can
install it, run it, and have it play nice with their other apps without
too much fuss, then that's all they need or want to know.

This is the polar opposite from the current OpenACS community,
which is used to thinking of it from the inside out. We need these
verticals to feel like simple, monolithic apps from the perspective
of the buyer and the typical admin.