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
