On Aug 30, 2012, at 5:04 PM, Russ Allbery wrote: > ... > Keeping track of and communicating the state of documents is one of the > things that the working group chair normally does in the IETF process. > Again, I think this comes back to an issue of lack of time among the > people in a position to do the work. > > ... > > My broader point here is that these process problems that you perceive all > come *directly* from a lack of time and resources. These are the kind of > process problems that just don't happen in standards working groups where > there are multiple people actively engaged, because people will constantly > ping state or will just start taking over work that goes undone and > driving it forward when other people run out of time. > > However, the level of critical mass required to keep a standards process > viable is much higher than the level of critical mass required to keep a > software project viable. Standards processes will stall out completely in > "everyone is waiting for everyone else to do something" modes at a much > higher level of activity than software projects. With software projects, > if there are only a few commits a month, one can still make some semblence > of forward progress; with standards work, that just doesn't happen. > > The complaint that you have, that the process is opaque (or the related > complaints that I've heard in other standards groups that the process is > too heavy-weight or too burdensome), are standard symptoms of that failure > mode. They happen with Debian Policy as well. But as soon as one manages > to achieve critical mass, my experience is that those complaints almost > magically disappear, either because people get familiar with the process > by engaging in it regularly or there is sufficient critical mass to > achieve consensus on changing the rules in ways that make things more > efficient. That's why I believe those complaints, while real, are > symptoms, not root causes.
I'm with Russ on this one, and 'critical mass' is the key phrase. I've worked on smaller open-source projects, some extensively. I saw two items which were critical to keep an open-source project going. The first was recognized authority, the second was critical mass. For larger projects, there might be a third, recognized direction. Recognized authority means some person or small group is recognized and respected as those who decide what goes in and what does not. The key words there are 'recognized' and 'respected.' As examples, see FreeBSD, Linux, and a number of others. I used to work a lot on elm. When Dave Taylor handed it off, Rob Bernando fairly quickly became The Guy who said yes or no. When Rob died, nobody ever achieved that status and things petered out. Critical mass came in two ways on those projects. One was when the project was small enough that a single person could make significant improvements. Bernardo was the major elm contributor, and his leadership by example quickly became his de-facto leadership. With Rob actively guiding people to co-ordinate tasks and making them do contributions 'the right way'. He rejected one feature with a comment something to the effect of "This glues a bag on the side of the program. Go inside and do it right." The other is when the project has easily sub-dividable parts. FreeBSD falls into this class with the ports system. It allows enthusiasts to contribute to small, self-contained pieces without pressures of time and co-ordination. If they fail, major goals (eg, kernel changes) are not delayed. Conversely, if some system-wide change encourages a change to all those ports, there's an army of folks who have responsibility and authority to make those changes. Having both responsibility and authority encourages them to be active, and they get the immediate feedback that volunteers need to feel appreciated. With AFS there is no easy divisibility. In this, it's more like a kernel. Both the linux kernel and freebsd have much higher bars for code contribution, and for obvious reason. In both cases, the recognized authorities vet contributions and co-ordinate work among the volunteers. Structurally AFS is more like a kernel than a small program or group of programs. That makes it difficult for people to contribute (higher bar) and contributions may go some time from acceptance to actually appearing in the release. In turn, that makes critical mass more difficult. The contributors have to be more committed, and the bar they must reach is higher. Both mean that casual contributions are rare. For significant work to occur, significant workers must be sponsored in one way or another. IMHO the critical mass for fbsd kernel and linux occur because enough commercial entities sponsor that work. I just don't see that happening with oafs at the moment. Maybe when the economy improves . . . and maybe not. Steve _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
