* Roy T. Fielding <[EMAIL PROTECTED]> [2005-07-29 11:44]: > Visibility is an essential aspect to collaboration and equal > participation. Whether or not you believe that a group of developers in the larger OpenSolaris universe should have a choice about whether their ongoing work should be public or not, I think that it's peculiar to assign blame for the presence or absence of visibility to the choice of SCM tools.
Project visibility is increased through regular use of many forms of online communications mechanisms. Project teams that propose large or fundamental changes involve more communication, more discussions with architecture review, and more coordination with other project teams or with experts in affected areas. Smaller sets of changes can successfully integrate with only code review and integration approval. Intermediate changes might need a very brief architectural check, or specific consultation with an interested group. Communication in large projects can involve any or all of: public source code repositories (in a company wide directory), web sites, multiple mail aliases, and, in some cases, IRC channels. I suspect if you polled project leads today, they would speculate about syndicating both their web site updates and their repository integrations. Of course, meetings and mail exchanges with architecture review and release teams, in addition to their primary purpose, also informally disseminate knowledge of the project to interested parties within the constituencies of those boards. > Interestingly, this teamware effect is also found in Linux > development, which in spite of its open source nature has never > been a collaborative effort in any real sense. In Linux, > individuals build trees on their own and make changes in their > own projects. When done, the hardy folks among them enter the > process of convincing one of the benevolent dictators to accept > and integrate the changes (as they see fit) with their next > revision. The "community" only participates in the sense that > code eventually shows up in the unstable release path. [elision] > Folks here keep using Linux as a model as if it were the paradigm > of open source development. I think you should be looking more > closely at the FreeBSD and Apache styles of development, which > have successfully integrated strong peer review and stable > interface revisions in the same manner as Sun but *with* true > community collaboration. I think you will find that such communities > closely match the values held by Sun engineering and yet are able > to collaborate as equals. I don't believe this is an "either/or" choice for this community, both in the sense that a particular SCM choice would lead to one model or the other, or that these are the only two viable community models. The internal process currently generates a product from the contributions of over 800 committers per release to ON alone,* with disjoint architecture review, test development, integration, and software release. The architectural and release acceptance processes remain objective in general, despite large (and--I should know-- controversial) changes being proposed and completed. Incomplete proposals are given guidance and, when appropriate, connected to teams working in related areas. All process interactions are documented, and can be used as models for future work. If we recharacterized the eligibility and manner of selection for the seats on the technical side, and replaced the business input side with a community driven equivalent, wouldn't we have a reasonable third model for pursuing scalable community development, with a documented process? (Has there been a discussion of where the current process, with its entities restaffed by community selection, and without reference to specific tools choices, has identifiable shortcomings with respect to collaborative development?) I suppose an alternative way to look at it is, "could a large group really produce a complex product *without* a reasonably effective form of collaboration?" - Stephen * This count undercounts individuals as team commitments are integrated by a single team member. Furthermore, these committers come from different organizations and have different aims that are somehow reconciled. Beyond that, there are other bodies of code and documentation with their own overlapping sets of committers. -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
