Glen writes:

"But, again, you're being very binary.  Practically, each member will be a 
member in part because they're aligned ideologically, in part because they 
contribute to the mission, and in part for promotional/egotistical reasons.  
Those sets aren't disjoint, regardless of what the participants think about 
themselves."

Sure, ideological and technical preferences and selfish motivators can be 
correlated and causality can be hard to pin down.   I'm claiming in my case low 
correlation, but not no correlation.   

Suppose individual preferences are represented by universal bit strings.   The 
bit strings can encode floating point numbers or yes/no, or triples to say 
yes/no/don't care, or programs or whatever.    Then there are other bit strings 
representing something global like Hackage, or the Library of Congress, a 
software company's intellectual property, or what's on Food Network.    Couple 
all the individual preferences to the global bit strings as an Ising system 
with random weights. 

A clever marketing department (or a politician) figures out what bits matter 
and directs resources to select/change their bits to change frustration in the 
system to make their bits more crucial -- to be towards the center of the 
network.    They can only have so many bits, so they have to choose the right 
ones.    User-facing tools are an instance of those bits that happen to be 
strongly correlated to a lot of other individuals' bits.   It's arbitrary what 
the semantics are for the bits.   It's just history and a popularity contest.   
But investment will occur in controlling the state of an evolving set of owned 
bits so as to maximize influence the evolution of other bits.   Meanwhile, 
preference bits of an individual have broader connectivity to other preferences 
(and their own) and global state bits.  Different communities would be seen 
from the user-facing software vendor as isolated graphs given some minimum 
cutoff for what is a connection, and their cutoff would be relatively h
 igh compared to a free software developer.

My claim is that free software developers, and GPL developers in particular, 
have a preference for exploring this broader type of connectivity, and are 
especially interested in the frustration of the interconnections amongst the 
global bits than in the relationship between individual preference bits or the 
relationship between the individual and global bits.  Any slice or subset of 
bits might not be interesting by itself, but the concept of growing and 
compressing the totality of global bits is a core value.

> If FOO and BAR represent different kinds of strong technical preferences then 
> that could explain why cooperation around multi-aspect software is harder.   
> There's too much to fight about.   But then consider loose cooperative 
> efforts like Hackage, or CTAN, CPAN, CRAN, etc.  each representing millions 
> of lines of code.  To say these aren't multi-aspect is absurd.   They are 
> very, very high dimensional, interdependent, and open-ended.

"Yes, but it would be a stretch to think of things like CPAN as user-facing 
tools.  They are more middle-ware or back-end.  At best, you can only think of 
the front-end script that accesses the databases as the front-end part.  And 
that's certainly not multi-aspect.  That /usr/bin/cpan script has a very narrow 
focus in handling the packages."

I don't mean the script or the tool to manage the collection, I mean the 
collection.

"These collective efforts are more like federations than applications.  And 
federations are methodological approaches to handling large sets of opinionated 
members ... like the EU or the US.  They are explicitly _designed_ to handle 
the extremists and their _splat_ of opinions on everything under the sun, 
because they allow even the extremists a way to focus in on the minimal 
agreement required to cooperate."

This goes back to the Cathedral vs. the Bazaar.  Large commercial organizations 
aren't automatically cathedrals just because they assert a mission.   A plan 
needs to be identified and socialized over and over.  That negotiation acts 
more like a Bazaar -- figuring who can do what, who they can work with, and how 
to reward and control them.   A small organization of like-minded people can 
take the cathedral approach straight away but will be limited by available 
manpower.  (Assuming there is in fact a distinction between conceptual work and 
detail work at all.)

Large hierarchical organizations of the kind that make most user-facing 
software have some small group of people making executive decisions.   They are 
just people though and not _that_ much better than the people on the leaves of 
the tree.  So they cannot take on fundamentally _harder_ problems, they can 
only keep throwing human resources at it, provided they can keep their story 
straight about what problem they are solving.   A hard problem is one that 
takes more intelligence to solve and that will be limited by individual human 
ability, not just orderly communication and a command and control apparatus.

Marcus
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

Reply via email to