Sincerely,

Lee Iverson
leei@ai.sri.com
http://www.ai.sri.com/~leei/

SRI International
333 Ravenswood Ave., Menlo Park CA 94025

Originl Source

How can DKR principles be applied to large (or small) scale, distributed open-source software development?

Scenarios

In a large scale sense our target is to augment the ability of Open Source Software developers to effectively collaborate.

In the following we articulate the following levels:

• General user scenarios
• Tasks within these scenarios
• Requirements directly related to tasks

1. A developer solicits interest in a new software project:
1. Articulates goals and requirements.
2. Relates his plans and goals to existing projects.
1. The system cooperates well with non-OHS managed projects
2. The system interacted seamlessly with other OHS enabled projects.
3. Identifies and evaluates software upon which the system will be built.
1. The system integrates legacy source code
2. The system integrates legacy documentation
3. The system operates well with various source languages
4. Gathers a community of users and developers.
1. The system is equally open to active developers and both active and potential users.
5. Engages in detailed design discussions comprising face to face meetings, live chats and collaborative online development of specifications and architectural plans.
1. The system is useful live in face-to-face meetings
2. The system integrates and archives live online chat
3. The system allows for multi-author development of plans, specifications and documents
6. Manages the tasking of various pieces of the development project to a distributed group of developers.
7. Monitors development and adjusts specifications and goals as this progresses.
1. Design documents and DKR modifiable throughout project
8. Develops developer and end-user documentation based on the DKR that has been developed. The developer documentation may be presented as a tour through the DKR.
9. Transitions from initial development phase into release process.
1. An experienced user, likely one of the original creators of the system, is programming, managing releases and leading focused development efforts:
1. Edits source code and developer documentation maintaining close relationships between the two.
1. Links and keyword references should be managed automatically.
2. Patches to sources should be managed and associated with both notes and/or discussion threads and bug reports
2. Manages discussion forums consisting primarily of developers and sophisticated users with the goal of developing and adjusting design and implementation of system.
1. Notes about or towards implementation should be encouraged to be public and associated with sources and other discussions or bug reports
2. Discuss implementation or bug-fixing issues with interested developers. Focused discussions should be discouraged from ?going offline? and should instead be based on dynamically created restricted-membership forums.
2. A new developer comes aboard and needs to familiarize himself with the code, documentation and social structures of the development community.
1. Browses the developers documentation and source code.
2. Examines current bug lists and chooses small ?starter? projects.


 

3. A user of the software.
1. Submits a bug report
2. Browses documentation
3. Asks questions of developers or other users
4. Create or participate in user communities

Sociological Perspectives

Typical open source developers are iconoclastic and come with a nontrivial amount of tool-oriented inertia. They are very attached to the development tools and host OS that they have used until now. The are typically motivated in their choice of development efforts by a desire to use the tools they are developing.These observations lead to a series of requirements. Any proposed solutions must:

1. Integrate with existing tools
2. Augment existing tools
3. Be built on respected open source technology
4. Work toward the establishment of open standards
5. Be as cross-platform as possible