This isn't what I think collaboration "is". This is what I think the best form of collaboration should be for SAIL. The page isn't complete yet.
Low Risk Low Overhead Collaboration
Low Risk Low Overhead Collaboration seems like a good way to describe how I think SAIL should collaborate. Each group independently produces libraries, tools, and documentation. The libraries and tools made by a group meet the needs of that group. Other groups are able to use these libraries and tools. The groups have regular meetings so each one knows what the other is working on and what problems they are trying to solve. If group A decides to use a library or tool of group B then group B will help them.
This is form of collaboration is only slightly more work than following open source practices. The extra work are the regular meetings and giving priority support for shared libraries.
Risks and Responsibilities
The SAIL community consists of organizations and developers. Most of the developers work for one of the organizations.
These organization developers have responsibilities to their organization, and they have to balance these with responsibilities to SAIL.
In any software development there is risk. There is the risk that the development will not be completed on schedule. There is the risk that the software will not meet the needs of users. There is the risk that the software will not be extensible after some initial release. These risks are increased the more developers there are working on a project. The Mythical Man Month describes this pretty well. So collaboration then also increases these risks. So the nature of the collaboration should attempt to minimize these risks.
Failed Collaboration Story
Developer Group A and Developer Group B are collaborating on creating a piece of software. These two developer groups work within organizations that need this piece of software. Lets call them Organization A and Organization B. The developers tell their respective organizations that the software will be completed and meet their needs. The two groups decide to separate the work into 2 separate parts. After several months group A is making good progress on their part, but group B is not. It is clear that the software will not be finished on time. So now the developers have to tell their organizations that the software will be late. In some cases being late is not an option, so the project fails.
It is inevitable that some software projects will not succeed, there are examples of this all over. So the model of collaboration needs to take this into account. The essential issue is that a developer or group of developer says, "I(we) will have this functionality working by this time". And they don't