Forum OpenACS Development: Re: The User Information Elephant
I think you have a really important point. Since the code is GPL you have no means to coerce anyone to do or not to do anything. However, Sloan, AISEC and other such institutions are banding together to form the dotLRN consortium so that they can address exactly these issues.
The processes are still being worked out; in fact I think it is discussions like this that help develop the processes. Here is how I imagine it working for functionality like user demographic information management.
Ideally, an open spec, design and collaborative development process leads to as general code as possible. However, we all know, as in Pinds Rule of 5, that a totally general solution is not always possible or desirable the first few times you solve a problem. Often we will end up with situations like the one we are in where different consortium members have implemented different solutions.
What should the consortium members do when this happens? That will be for them to decide but I hope they open their code, use cases and needs analysis and work together towards creating a solution that meets all their needs and hopefully the needs of other current and future users.
At some point general functionality like managing user data needs to get into the dotLRN core. Through participation in the consortium I expect that Sloan and AISEC will find that that core functionality meets their requirements and that there is a reasonable upgrade path from their current code.
I think that user consortiums can vastly improve the chances that future code will be compatible with the requirements of the clients who paid for the initial work, but I want to also examine what happens if a client isn't a member of any consortium. If you create functionality that has general usefulness (like managing user demographic information) and you don't release it then someone else will write code with similar but likely incompatible functionality. The chances of this code being useful to you are pretty low (say 5 or 10%).
If you release your code to contrib and people start building on it the chances that someone will do something that will be helpful to you in the future go up dramatically. Maybe they find a bug, improve a query, or add a new feature. When and if you want/need their improvements you can go look at what they have done. The chances of getting something useful have risen to maybe 50%.
Now in the non-consortium member case lets imagine that at some point in the future there is an official version of the functionality they had to custom code. There are no guarantees on the features meeting their requirements, but the odds are sure a lot better if its based on their original code! No one is going to write their upgrade scripts for them, but they are likely to be a lot simpler and cheaper if its based on their original code.
