Open Source and Authority

Authority is not a person, but a process. In the standard corporate software development world, authority often takes the form of a person, a manager of a product's lifecycle who in turn controls the livelihood of her team members. In the OSS movement authority may be vested in the form of the person (albeit a person who often has little remunerative authority), but it can just as easily take the form of the process. And in any case, any lack of authority's existence can greatly diminish the chances for a project's success.

Recently on the Bootstrap List, there's been a set of discussions about licensure of the product and how this question of licensure could be key to the projects sucess in the marketplace of ideas.

In my thinking about it, it may be that the licensure question, and the development process its answers engender, may be key to the projects success, but not in the marketplace of ideas, but in the internal market of development itself. The subtlety is not that the license type is key, but that the license discussion exhibits the needs of the process.

I'm no Eric Raymond, only a casual observer. But it seems obvious to me that the key to true success of an OSS development model is in the authority which is laid onto the project. If I go to Sourceforge or Freshmeat, I can see a multitude of products under development. Some of them are even bootstrap institute friendly in both goals and license. But for the most part they languish there, stale at relase 0.13 "builds". I think to some part this is because there is no authority for the development beyond a momentary itch and rush of excitement. For development and software to be sustained, authority must set in for the project.

In his note that I see as a challenge to the list, Chris Dent says in essence the best tool that could be provided for the bootstrapping of OHS development would be a "pocket-guide spec". It's this succinct but overriding focus that drives the best OSS projects. In order for an itch to be scratched, one has to know where the itch is to point your finger or backscratcher. One needs a map to the territory, even though the map is NOT the territory to be scratched.

In the case of the FSF, much of that driving force comes from Richard Stallman who - though he may not be involved with the day-to-day decisions that drive FSF products, has been so deeply ingrained in the process for so long that his spirit is there. In the case of Apache, there's a concretely defined goal that has driven the development of the code (and I note that Chris has noted in his referenced posting the corporate goals that made much of this development possible). For a product like Jabber, the development has moved from being the modus scratcherandi of Jeremie Miller to being driven by the Jabber Enhancement Proposals (JEPs), who present a more decentralised but less ontrolling focus - a model taken from Python and well used in the Perl community as the newest revisioning - still vetted by Larry Wall, but driven by the community.

In the case of the OHS, there are some snapshots of this authoritative model, but discussion on the lists wanders adrift in the commons without authority being envisioned (and, as the conversation wanders, the energy toward running code is taken into other pursuits). Does this mean that Englebart should step in and drive development and modelling? Perhaps not. But Bootstrap Institute, if not Doug himself does need to step in and provide more authority, a quickbook and focus, into the process.

[note: since I started corralling (perhaps unsuccessfully) these thoughts, Eric Armstrong has begun what I see as attempts to move the list to this agreement on our authority.]

Posted by esinclai at May 22, 2002 05:48 AM |