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

I'm going to talk about one very specific issue which needs addressing.  Perhaps in raising it I can help Caroline and Al understand where I'm coming from.

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