[AFS3-std] Re: IBM will not re-license OpenAFS .xg files

[Steve Simmons]

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.
>=20
> ...
>=20
> 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.
>=20
> 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.
>=20
> 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=20