How would the OpenACS project view .LRN and .MINE, then? Would .LRN and .MINE be just two competing projects that are based on OpenACS? What would happen if the two projects required different changes on the OpenACS core?
Good question, Neophytos.
I think the answer is fairly simple though. Both projects are in the same boat. They can request changes to OpenACS but can't require changes.
This could lead to a chaotic situation if we're not careful, and I think we're all aware of it. This is why the need for OpenACS experts to be involved in the technical side of dotLRN governance (under either proposal) has been emphasized. If you start a .MINE project and want smooth coordination then you'd be well-advised to include OpenACS expertise in whatever management system you set up for your project (of course you're an OpenACS expert yourself, making this a not terribly good example, but I imagine you get the point)>
What is the underlying motive for projects to play well with OpenACS and for OpenACS folks to work hard to play well with projects based on our code base?
The fact that everyone recognizes that a fork would be very expense, not only technical but in our efforts to evangelise OpenACS, dotLRN, .MINE. .YOURS etc.
It's true that at some point some folks may decide the cost of forking is less than the cost of not forking, or just fork for the hell of it. That's part of the beauty of Open Source, since we can't stop it irrational forking there's not much sense in worrying about it :) What we can do though is work very hard to make sure that sticking together is in everyone's best interest.
