Date: Fri, 31 Jan 2003 15:57:12 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Michael Lucas <mwlucas@FreeBSD.ORG> Cc: Giorgos Keramidas <keramida@ceid.upatras.gr>, advocacy@FreeBSD.ORG Subject: Re: [bsd-advocacy] Re: Draft: Proposed FreeBSD PubRelproject Charter Message-ID: <3E3B0D58.4D2FB13C@mindspring.com> References: <007501c2c898$b2fbdd30$0502000a@sentinel> <3E39B755.34A8253@mindspring.com> <20030130235537.GB758@gothmog.gr> <3E39C28F.F26DC60E@mindspring.com> <20030131081028.B25507@blackhelicopters.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Lucas wrote: > On Thu, Jan 30, 2003 at 04:25:51PM -0800, Terry Lambert wrote: > > In particular, the core team members and the average committers > > do not value PR work sufficiently to give it, say, the moral > > equivalent status as "GEOM" or other code-work. > > Actually, I have to take some (mild) objection to this. > > My press relations work within the Project has been greatly supported > by both core and re@. It has required a certain amount of education > on what PR means and how the game is played. These people aren't > dumb, and they aren't even ignorant; they just haven't played that > game before. We have finally been able to arrange for a PR Newswire > membership (thank you, Foundation!), as it's been demonstrated that > without that a press release will go nowhere. My point was to how they value PR. The common response to most suggestion/complaints/questions/etc. is a terse "send patches". The problem is that a marketing program can not really be effective without some form of project sanction, *if* it's to take place within the project itself. The intent of placing oneself in a subservient position is to obtain defacto sanction. But in doing that, you come not as a peer, but as a supplicant. Various people have put themselves forth, in the past, producing publicity for the project, etc.. Brett Glass and Jordan Hubbard are examples. Jordan was mostly effective because he could speak on behalf of the project leadership, and do so with sufficient reserve that he was able to commit resources through his leadership. He was "official spokesperson", in part, because of his membership in the original core team organization, and in part, because of his ability to "send patches" -- both in their generation, and in his personal ability to commit them to the source tree. These days, there is a significant amount of buearocracy, and the "review process" has engulfed the ability of people to personally make a difference in project direction, merely by being a willing contributor of source code. At this point, in fact, merely being a willing contributor of source code *with a commit bit* is not enough to avoid sanction for changes to the status quo. The organization has become insular, and self-defensive against change; this is not a recent thing: it's been an ongoing process, but that doesn't make the effects: John Dyson leaving, Jordan leaving, Mike Smith leaving, other people dropping out of participation (Satoshi as "ports-meister", etc.), and so on. In order to be effective, any focus of change has to occur outside the normal channels of the project, proper. This is as true with a PR effort as it is, for example, with KSE, or ports to other CPU architectures (all current examples). People are, at this moment, arguing whether or not a "config" change is going to be permitted, even though it's a necessary step in porting to the PPC and MIPS architectures. People are standing in the way: they are not asking how the work should go forward, but *if* it should be *permitted* to go forward, as if volunteer efforts required sanction to take place. Well, they do, if they are to occur under cover of authority, in the context of the project, proper. Someone made the suggestion that the PC98 architecture be converted to this new style of "config". The reasoning behind this was transparent to me, and so I threw what philosophical weight I could behind the idea: to demostrate to the skeptics that such a change would not impact their daily lives, so they could feel "safe" in not hindering it. > Will re@ hold to a release date for marketing purposes? Probably not. If there were official sanction, then yes, it would. It did. There is historical precedent for this in FreeBSD. Jordan was in a position, as both PR contact and release engineer, to be able to make this happen. He was able to synchronize releases with major events, and with press releases that had lead times appropriate to the publication/forum. We all knew about the Usenix release, for example, and Jordan was there to hand out CDROMs with the new release on it, coincident with the release appearing in the media. At this point, though, you're right: "re@" would not hold a release date for marketing purposes. And part of the reason for this is that they would feel that this would be giving power over them to marketing, which is something that they don't value enough to yield power over, even if the yeilding is in fact an illustion of when a disk is cut, rather than when a tree is tagged, so that a code feeze doesn't mean voluntarily ceasing to make checkins on the HEAD branch. > But that's part of the nature of how open source projects staffed > almost entirely by volunteers are run. If we had a highly paid staff > of developers, that would be a different matter. Yes and no. A business is a system, and a volunteer organization is also a system. What it comes down to is the core values and mission of the organization, not whether or not people are paid for their efforts in the coin of dollars, or the coin of ego, or some other coin, such as wanting to leave a better situation for those to follow. It's true that you can't schedule volunteer resources -- unless they volunteer to be scheduled -- but it's also true that the same thing that motivates you to volunteer effort can motivate you to show up at your job, Monday morning, instead of showing up at a competitors HR department. That thing is called "vision". And, while the project attempts to create a focus, and does moderately well at supporting the feedbck mechanisms that reinforce particular focus for efforts, in the end, focus is no substitute for vision. When people tell you to focus on a goal, what they are really saying is that they are managing a crises, and they can't see any farther than the immediate short term goal -- that they have no roadmap, are as clueless as the next guy as to what the future will bring, and are focussing on the short term as a way of compensating for this lack of direction. The only thing they know for sure is that they have a means of stomping out fires, and they can always wait for the next fire, and demonstrate how good they are at stomping them out, and if it's a slow week, they can start their own. > "The FreeBSD Project" is not just about code. It's about producing > something. For example, we on doc@ are held in high regard. While at > times I may feel inferior because I cannot follow the latest > discussion on kernel architecture in arch@, I have *never* been > treated as a second-class citizen just because I don't code. That's > because I produce actual content which other people can use, and I > give it away, just like the programmers. You are in the same boat as a regular developer... for the most part. Because you commit something to the source tree, it doesn't matter that it's documentation, your contribution is visible, and, if anyone cares to make the effort, at least measurable. On the other hand, documentation *is* a second class citizen, to code, according to the project powers, or there would be a documentation requirement for new subsystems. I'm firmly convinced that the major reason people have not converted all the code from the old way of doing things to the new way, when it comes to APM vs. ACPI and the APM "screen saver", or "newbus" for everything, or "GEOM" for raidframe and Vinum, or making everything "devfs knowledgable" or the AHA15xx drivers not being there when CAM first went in, or the AppleTalk, X.25 and ISODE support dissapearing when the new routing code went in, etc., etc. ... derives from the fact that there was a lack of documentation. And if documentation were a first class citizen, then there would have been a requirement that the authors provide at least enough data to document their APIs, if not their code, so that third parties would be able to actually use them, instead of code "getting stale" (impossible: there is no such thing as bit-rot, there's only half-assed porting jobs). The most apparent example of this trend right now, in FreeBSD, is the SMP locking: there's not enough documentation for people to be able to contribute usefully to the project, even if they are knowledgable engineers, unless they already have built their kindom into the area where they are entering: people can only operate within restricted domains, where they have credibility to spend. Credibility that they might not gain back, if spent this way. Some obvious questions, which should be answered by documentation: o What is the overriding locking philosophy for the SMP effort? o Do you lock a code path? o Do you lock a data object or container? o How do you make sure people aren't using one lock to achieve the effect of the other? o What's the quick way to fix a lock order reversal? o What's the philosophy about holding locks over function calls? o Is it an attribute of the function being called? o If so, how can you know ahead of time which functions have which attributes? o Where is it documented? These questions are only vaguely answered -- not well enough that code does not ship with daily posts to the -current list about "LOR this" or "LOR that". > Advocacy work is unquestionably work. I happen to know that commit > bits have been offered to certain advocates who produce neither code > nor committable docs, but their advocacy work has been important and > far-reaching enough that we feel they have earned the right to the > @freebsd.org address. In the cases I am aware of, the advocates have > turned down the offer. (I'm not going to name names here, at least > one person involved is on this list and I don't care to either > embarrass him or subject him to a flood of email of "why did you turn > it down?" It's nobody's business but his.) Philosophically, I can well understand the refusal. If the commit bit is a plaque on your wall for service to the project, rather than a gating factor, it becomes a goal in itself to obtain it as a reward. It is no longer a tool to use to achieve an objective, it is an ends in itself. I suspect that there are many people who, after an initial amount of effort after achieving their commit bit, and getting the "FreeBSD Committer" to put on their resume to imply to potential employers that they are buying some small editorial control over the project with the employee, have not committed anything for a very long time. I also suspect that there are those for whom having their name in the CVS logs is more important than actually doing any real work of value, and they make large commits of mechanical changes, in order to have their name attached. There might even be behind-the-scenes versions of "core wars", where coup is counted by who has touched a file last, or who has the most files with their initials on it, or some other arbitrary (and ultimately meaningless, in terms of moving the project forward) measure. It would be very interesting to see statistics, up to the point that this posting was made, and potentially made people rethink what they were doing, or at least think about making it less obvious. > Internally, the "FreeBSD Project" is highly interested in advocacy > work that creates content. Some of this content is useful for > inclusion in one of our source repositories. Some of it is not. If > it is not suitable for inclusion in our source repo, we don't need to > do anything except say "thank you." The valuation is high for committable material. I've generated a lot of it myself. > But we definitely appreciate people who go out and pound the pavement. > Since pounding pavement does not produce content, however, there's no > need for action from "The FreBSD Project." All we have to do is keep > producing content for others to advocate (or not advocate, if they > choose). Who has written the most articles mentioning FreeBSD? I would bet that the person who, by far, holds the record, is, in fact, well known to us all. But their contributions are uniformly disparaged on the mailing lists, and they have, in fact, been banned from some of them in the past, or simply "kicked off", and forced to resubscribe. > PS: Why do I keep putting "The FreeBSD Project" in quotes here? Well, > that's because in my opinion it's a lot more amorphous than people > seem to think. There is no Project; there are just people who work on > FreeBSD. There is no person or group that can approve your project to > advocate FreeBSD, but there is nobody that can tell you *not* to do > it. True, you cannot send out a legal document in the name of > FreeBSD, but you can do dang near anything else. The power derives from control of the source tree, and the tokens of power which are handed out are community membership, in terms of commit bits, and mailing list membership. What is given, either explicitly, or tacitly, thorough it's ability to be taken away. One of the main reasons I've advocated avoiding yielding internal power (e.g. "PR core team member removal") to the project itself is to avoid involvement in this funnel of centralization, and immediate inferior hierarchy relationships (as docs is to the rest of FreeBSD committers). You are unlikely to be nearly as effective in any PR effort, if you yield the power to technocrats. They will not sabotage you intentionally, but the effect will be the same as if they had. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E3B0D58.4D2FB13C>