On 07/15/2015 08:08 PM, Marcus Daniels wrote: > If one wants a tool to do a job, why would that person have more opinions > about tools not in that category? They just want that kind of tool. If > FOO and BAR are competing, then it is different because BAR is like non-FOO. > But that's not about being opinionated, that's about protecting an > investment. FOO and BAR don't need to represent an ideology, just some > random goal that for whatever reason the supporters happen to grow a > community around.
Well, we had been talking about community for community's sake. If we assume that the 2 categories (community purely for mission vs. community for the sake of community) are not disjoint and that there's a spectrum between them, then it's relatively easy to see how a given community, if large enough, will contain a mix of ideology and practice. In other words, we can assume everyone has at least a little ideology, even if it only manifests as slight preferences (like vi over emacs). > If FOO and BAR represent ideologies, cohesion can help. For example, I > would always choose to work on GPLed software rather than not if my intent is > to make it free. In practice, that would typically mean to add-value to > someone else's tool. My selection criteria is the philosophy behind the GPL, > not the details of the tool itself (provided the tool is technically > adequate). I know other people that can't imagine adding value to another > person's tool. While they might give their work away, they would do it for > promotional or egotistical reasons. They don't have this community's > ideology. 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. > 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. 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. So, collectives like Hackage et al don't bolster your argument, they refute it. They're examples that the members with loud opinions on one thing are likely to have loud opinions on other things. Hence, a federation is needed to help them minimize the amount of agreement required to cooperate. > So I'll return to the view that proprietary mainstream user-facing software > holds its place not because it is multi-aspect, but because its aspects are > well understood and curated (and as Roger points out the marketing and > product development are intertwined). Emacs is user facing but in > contrast users come to appreciate Emacs rather than Emacs coming to > appreciate (pander to) its users. Emacs is what its developer base wants > it to be and everyone else can get lost. Programs like LibreOffice or maybe Eclipse do bolster your argument, I think. I don't know about Emacs. It's a strange beast that I think has survived for reasons other than coherence around a mission. But I'm certainly willing to be wrong, there. ============================================================ 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
