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.
