Developer Support Issue Summary

General Note on Scope: 1 Topic or Two?

I think this topic covers two realated but distinct issues: (1) the general developer support that both commercial ventures and open source projects try to provide with the information needed to be successful in building on top of the product released by the software vendor -- docs, sample code, etc.; and (2) the items important to building a community with additional levels of involvement, ranging from testing to localization to involvment within the core development itself. I've lumped them all together here, but perhaps they should be spearated.

Problem Summary

• We both want and need to develop a vibrant community based around Chandler. We need this because:

• • The project is large; reaching critical mass is a challenge and more involved, motivated contributors will make this happen faster

• • The scope of the project would benefit enormously from other perspectives and use cases

• • People will think of ways to use Chandler that OSAF won't

• • We hope others will develop Chandler to meet a wide range of users, such as the enterprise market

• People need entry points through which to become involved in Chandler development.

Brief History

• OSAF was founded as and is committed to the Open Source model.
• We've taken a number of steps to provide transparency for the project and encourage people to get involved: (website, mailing lists, wiki, open bugzilla, open CVS, status reports, early release of code to prove we mean it when we say we're "open source," an IRC channel a development locale and scheduled IRC sessions.
• We've provided a couple very primitive tools to help people get involved: the How to Write a Parcel tutorial being the most obvious example, comments in the code itself.
• A number of exceptional contributors have become involved through these early steps.
• Response to the 0.1 Release was a bit of a surprise. Over 30,000 downloads, but almost no comments on the code or the related documents. To date, most (not all, Andrew Francis' work with Andy Hertzfeld on the Agent framework is a notable exception) volunteers who have made significant contributions to core development have all been in the SF area, come to the OSAF offices and received intense one-to-one briefings to bring them up to speed. The need for this type of interaction is not a good situation, either for OSAF or for community members who want to get involved.

Issue Summary

• Decide scope of what we think we can realistically provide in each of the following areas:
  • Well commented code
  • Documentation
  • Sample code
  • Focused assistance for developers with issues (via IRC, or jabber, or some other technique)
• Understand where developers can be most effective
• Learn culture of working in public and making mistakes in public
• Decision-making process should become transparent
• Our dev mailing list is pretty quiet, which discourages people from getting involved.
• Project's scope makes it harder for people to grok
• Key contributors (whether employee or volunteer) need to have a space in which they can speak publicly with confidence.

Risks

• I think many of the issues are owned by the group, which might be a bad sign.
• Easy to lose focus on things other than the code
• Requires resource commitment, either of developers or of others
• If separate people are involved, requires good interaction with developers
• Need to schedule time for this
• Maintaining updated information can be as difficult as creating it in the first place
• Volunteers are motivated by different things than employees
• Techniques which are effective in the corporate world may be less so in a mixed employee-volunteer environment

Known Answers

• Public communication.
• Design and Development process carried on in public forums
• Design and development discussions documented, findable
• Committment to communicate and document till it hurts.
• Tools to help developers:
  • Releases (no surprise here)
  • Sample code
  • Documentation
  • Well-commented code
  • Mechanisms for providing feedback
  • Easy to navigate web presence (www; wiki; or whatever)
• Develop guidelines for what key contributors should feel comfortable in asserting their view (e.g.,"I plan to implement X in this fashion.") without double-checking for a consensus.
• Identify areas and timeframe in which volunteers can "run with the ball."

Dependencies

• Development process
• Development needs to be public
• Progress on the code we release.
• Shared understanding of differing roles and responsibilities in the Chandler project

-- MitchellBaker - 13 May 2003

---

---

It might be appropriate to mention that we don't have a good process for taking patches.

-- DuckySherwood - 16 May 2003

---

Two suggestions to make this issue more tractable:

1. We roughly know what our community end-goals are. We are just unsure how to get there and how to ensure the project doesn't lose it's "soul". Perhaps a strawman timeline for how can we can proceed will help? This timeline doesn't have to be prescient, it's just a tool to help seek alignment and divide responsibilities so that key issues are owned by individuals and not "the group"
2. Another approach in the same vein could be to list a series of milestones we need to accomplish towards being a completely open community. For each milestone, we can then list what the requirements are to meet this milestone. e.g. one milestone could be "allow select community members to have write access to cvs repository" or "community starts writing key parcels", etc.