Neophytos wrote:
Well, after Lars post, I think we need to address this issue. [Lars, nothing personal]. I have nothing against people or companies maintaining packages outside of OpenACS but I think that saying that QWERTYXYZ is an OpenACS package should come to mean something.
I know at least one company/person who plans to distribute their packages built on top of OpenACS in a separate project and of course it's fine with me, IMHO -- in a way .LRN is doing the same, IMHO, which is also fine. But how does Lars bug-tracker (used as an example here) is different than those packages. How do you differentiate an OpenACS package which is subject to the development processes of the OpenACS project and a package that is in the CVS tree but has its own development processes, probably not subject to the development processes of the OpenACS project.
I think I agree with this, but I want to be sure I understand it. Are you suggesting that there ought to be some process by which some (formal or informal) governing body blesses a package as an OpenACS package, thus preserving the branding of OpenACS? If so, then I agree completely. One approach that some standards bodies take is to create two distinct labels: one for something that the manufacturer claims is compatible with XYZ and the other which the XYZ governing body has officially blessed. So, for example, you could have developers who claim their packages are "dotLRN-compatible" or "OpenACS-compatible" without anybody jumping down their throats, but they'd have to get permission to claim that their package is a "dotLRN package" or an "OpenACS package."
Now, in the case, where you have two or more organizations that are each claiming the ability to "bless" a package, you need means of negotiating between those organizations. Note that the problem is not, strictly speaking, an issue of both organizations potentially blessing the same package. In fact, that would probably be a positive thing, because it allows developers to leverage their work across both the base toolkit and the various vertical apps that may be built on top. No, the problem comes when the two bodies have conflicting code requirements in order to get the package certified.
How serious this conflict in requirements is depends on how central the package is. It probably wouldn't be too terrible, for example, if there needed to be a separate "dotLRN-glossary" distinct from "glossary." OTOH, if dotLRN had conflicting requirements for, say, the content repository, we'd have a pretty serious problem.
So, IMHO, OpenACS needs to work out a policy to sort out this sort of issue with developers of add-on applications, whether those developers are consortia like dotLRN or individual companies like Collaboraid. (And yes, I think this policy needs to come from the OpenACS community rather than dotLRN or someplace else. We need to set up ground rules that encourage people to build on top of OpenACS in a way that is fair to everyone and that discourages forking.)
The easiest place to start is with the core. It seems clear to even a non-techie like me that anything that belongs in the minimal OpenACS distribution should be owned by OpenACS. It may make sense to create a non-profit entity that holds copyright on the OpenACS core. Non-core packages are, I think, a bit fuzzier. We need a process.
Neophytos, is this consistent with your concerns?
