speculative Q

[gepr]

CONTENTS DELETED

The author has deleted this message.

[Marcus G. Daniels]

"The last one, in particular, seems to imply that those who are most likely to think a community really has a mission (as opposed to the illusion of a mission) are the most extreme of the bunch, the hard-liners, the obnoxious ones."  

To tie this back to the original question, I was thinking of actual open source projects.   It is common when a group of people form to build a software package that the concept for what the capability is, is reasonably clear to the founding members.  Make a better FOO.   Then, some other people come along and don't understand that mission or try to advocate a different mission, like another BAR mission.   The relevance of their input can be higher if they are productive people, but often they are not, and they are just in the way and taking up space, participating in advocacy of dubious value, etc.    It is different from a commercial enterprise in so far as "make a better FOO" is measured some way other than by ROI in money.  "Better" can mean technical properties that the group understands and see worth pursuing for its own sake.  

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

[glen ropella]

On 07/15/2015 05:07 PM, Marcus Daniels wrote:
> To tie this back to the original question, I was thinking of actual open source projects.   It is common when a group of people form to build a software package that the concept for what the capability is, is reasonably clear to the founding members.  Make a better FOO.   Then, some other people come along and don't understand that mission or try to advocate a different mission, like another BAR mission.   The relevance of their input can be higher if they are productive people, but often they are not, and they are just in the way and taking up space, participating in advocacy of dubious value, etc.    It is different from a commercial enterprise in so far as "make a better FOO" is measured some way other than by ROI in money.  "Better" can mean technical properties that the group understands and see worth pursuing for its own sake.  

Yes, but the same hypothesis applies: those with the most extreme opinions (about FOO or BAR) will have more extreme opinions about non-FOO or non-BAR, creating noise of dubious value.  And that would allow the middlings to be both productive _and_ there primarily for the sake of being part of the community, with little skin in FOO or BAR.  Unless what you're saying is that, in your experience, the hypothesis does not hold ... that, perhaps particularly where $$ isn't the measure, the extremists can have only extreme opinions about the 1 thing and that it's the cohesion of the extremists that predicts success?

But if that's what you're saying, then it's _not_ an argument for why there are fewer user-facing open-source tools than back-end open-source tools.  Since user-facing tools tend to be multi-aspect, if the hypothesis is false and someone holding extreme views about one aspect can have middling views about all the other aspects, then they can be just as productive re: the aspects on which they don't hold extreme views.  Similarly, they can cooperate nicely with others who hold extreme views about other aspects.  But if the hypothesis is right, then getting a FOO-extremist to work productively with a BAR-extremist will be difficult because they'll both be extremists in both aspects: hence user-facing tools will likely be built for money, not ideology.

--
⇒⇐ glen e. p. ropella
Then I'm afraid you'll have to cry


============================================================
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

[Marcus G. Daniels]

"Yes, but the same hypothesis applies: those with the most extreme opinions (about FOO or BAR) will have more extreme opinions about non-FOO or non-BAR, creating noise of dubious value. "

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.

"And that would allow the middlings to be both productive _and_ there primarily for the sake of being part of the community, with little skin in FOO or BAR.  Unless what you're saying is that, in your experience, the hypothesis does not hold ... that, perhaps particularly where $$ isn't the measure, the extremists can have only extreme opinions about the 1 thing and that it's the cohesion of the extremists that predicts success?"

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.    

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.

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.

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

[gepr]

CONTENTS DELETED

The author has deleted this message.

[Russell Standish-2]

On Fri, Jul 17, 2015 at 08:10:09PM -0700, glen wrote:
>
>
> 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.
>

I do know about emacs. It survives, because it is bloody good at being
a text editor, particular for programming. I suppose vi is the same -
I've seen some people make vi stand up and sing, but for me, its
behaviour when interacting with vt100 style terminals has always put
me off.

Cheers

--

----------------------------------------------------------------------------
Prof Russell Standish                  Phone [phone] (mobile)
Principal, High Performance Coders
Visiting Professor of Mathematics      [hidden email]
University of New South Wales          http://www.hpcoders.com.au
----------------------------------------------------------------------------

============================================================
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

[Marcus G. Daniels]

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

[gepr]

CONTENTS DELETED

The author has deleted this message.

[gepr]

CONTENTS DELETED

The author has deleted this message.

[Marcus G. Daniels]

"But the point I was trying to make with those 3 articles still stands: that people who join communities for community's sake are not necessarily only drags on, disrupters of the system.  They provide something like a dampening baffle that traps and eliminates the noise of the extremists, the purposeful missionaries.  In fact, without _enough_ of that sort of "middling" or "joiner", a project is more at risk when/if extremists fail to cohere.  And I think this is true in open source projects as well as proprietary ones."

Right, but from the missionary's point of view, the truth is out there, and if one project dies another will fill its place..  It is the truth that matters.

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

[Steve Smith]

Text Editing Nostagia Conflated with Bicycle Riding:

I learned to ride on paper tape and punch cards... kind of like one of
those toddler's early "walker" toys that looked like a flying saucer
maybe?  It had bumpers all around, a built in rattle, didn't move too
fast, and the sling-like seat was easy to clean.

Then I graduated to a tricycle with timesharing and line-oriented text
editors...  maybe one of the precursors to VI like ED or EX... it was a
big step up, especially when I got onto a CRT based terminal rather than
a line-printer or thermal style where there was a full record of your
mistakes and lots of paper to toss or recycle after a few hours of
intense editing.  My paper-tape/card experience made me very thoughtful
and careful about my work, but still... one could generate a lot of
paper.  It was interesting sometimes to have a record of your revisions
(a roll of yellow paper with every line of typing and every line of
"replacement" "insert" or "substitute" commands...   especially as I
typed all my creative writing papers in this mode... thought my CR
teacher didn't care for the line-printer style paper I submitted on....
she liked it better than my lousy handwriting, and she fortunately liked
the content of my work.

When VI  came along it was like my first Schwinn two-wheeler. The
ability to go back to EX commands on demand for things like global
pattern replaces was like training wheels...  I could always revert to
what I knew to get things done.   I *still* ride my first Schwinn.   My
road racing friends call it a "clunker bike" but it gets me around.

Most of you under 50 were screaming down the streets in those Plastic
Big Wheels you got for Xmas that year!

When Emacs came out, I wanted desperately to be a hipster and use it.  
By then VI had some syntax directed editing features, but for the most
part, Emacs just felt like climbing on a fancy english racing bike after
my comfy beach-cruiser style VI...  the seat was high and hard, the
handlebars were slung for aerodynamics, not comfort, and the gears were
mostly just confounding... VI with syntax-coloring and brace matching,
etc. was like adding a 3 speed hub to my Schwin...  a little more range
for low grinding hills and high speed "wheeeee!" down the highway, but
what do you do with those other 7 gears?  And don't you dare get off the
smooth pavement!

I now use whatever IDE is appropriate for a project (I feel I can
ride/drive pretty much anything with wheels, skis, tracks, or pontoons)
but when the going gets tough, I revert to my trustly VI (Schwinn
Cruiser with 3 speed hub, ape-hanger bars and well sprung fat gel seat,
and extra fat knobby tires for gravel, not for speed) and my array of
Unix Text processing tools like SED (cushman mini-bike) and Awk
(go-cart) and PERL (high-displacement dual-sport motorcycle with a full
complement of spare parts in the panniers, barkbusters on the handgrips,
electric and kick start, and flat-proof tires.

Really, text editing is just like riding a bike... you don't forget what
that first "real bike" feels like, and it IS fun to wipe the dust off of
it and cruise down the boardwalk ogling the young and the reckless with
their toned tans, but from one old fart to the rest of you, don't forget
the ape-hangers, the gel seat, and the three speed hub.    Nothing beats
a global pattern replace or building a chain of complex macros to "get
you from here to there in comfort and ease"!

Like Curious George, I can VI with both hands behind my back, doing a
wheelie while whistling dixie even though I only dust it off once every
few months or more!

- Steve

> On 07/17/2015 09:44 PM, Russell Standish wrote:
>> I do know about emacs. It survives, because it is bloody good at being
>> a text editor, particular for programming. I suppose vi is the same -
>> I've seen some people make vi stand up and sing, but for me, its
>> behaviour when interacting with vt100 style terminals has always put
>> me off.
> I agree (that both emacs and vi) are good text editors.  But emacs, at least, is much more than just a text editor.  I've used emacs as a window manager, spreadsheet, IDE, file manager, database, etc.  It definitely has multiple and diverse aspects.  But Marcus is right that it doesn't field the morons (or pander to users).  The same is perhaps even more true of vi.  You have to be a particular type of person to use the tool.  But I think I disagree slightly with Marcus.  Although it doesn't _pander_ to users, it provides a very navigable (damn near user-friendly, actually) exception system.  You don't have to be a rocket scientist to figure out what went wrong when you do something stupid.  You just have to be a little persistent.  Such an exception system is always necessary for a tool with such a diverse set of functions.  And that is in contrast to the sharply focused tools that dominate open source software.  Mess up the configuration of, say, postfix, and you could spe!
>   nd a long
>
> while trying to figure out what you did wrong.  So emacs is much more like libreoffice than it may seem at first glance.
>
>
> ============================================================
> 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

============================================================
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

[Marcus G. Daniels]

Steve writes:

"Really, text editing is just like riding a bike... you don't forget what that first "real bike" feels like, and it IS fun to wipe the dust off of it and cruise down the boardwalk ogling the young and the reckless with their toned tans, but from one old fart to the rest of you, don't forget the ape-hangers, the gel seat, and the three speed hub. "

I still have the motors skills for ed and sometimes still use it when an internet connection is slow.   The motor skills amount to using regular expression ranges instead of scrolling around, and making changes with what amount to using tiny context dependent programs to make the edits.   It does require one be very facile with tagged regular expressions.    It's not a crazy way to program, actually.  If one can't formulate the code change they want to make with code, it may well not even make sense.   And programs are just grammar constrained graphs, after all.

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

[Vladimyr Burachynsky]

If the truth did matter there is very little evidence of it.
Quite often a viewpoint from the empowered is sufficient.

We seem to have done pretty well thinking the earth the center of the
universe.
Knowing the truth seemed to be reason enough to end up in the market square
to be incinerated.

The Group decides what is true. Consensus Truth on the one hand and
Emotional Truth on the other are the only choices.
The emergence of alternative truths to satisfy the many solipsists is an
industry.

We sell cars to people who need a mobile platform for their cell-phones and
handbags.
A coffee cup holder may not be enough soon a car will show up with an
espresso machine.

Robot butlers and robotic chauffeurs in the ultimate version.

Selling or marketing technology  claiming it  will elevate one's status,
while serving as auxiliary memory prosthetic devices.
The cell phone removes the burden of remembering phone numbers and you can
have a photo for faces you forgot.
The new growth industry may well be machines that will speak for us
performing in a selected Stage style.
Shakespearian or perhaps Rabelaisian affectations.

Can we synthesize Basil Rathbone in a Sherlock Holmes-ian style.
Technology has a nasty side effect of making us stupid and proud of it.

Without extremists who risk immolation the human race would still be
cracking nuts with a rock.
The failure of extremists to cohere is no doubt a trait that allows  every
extremist to think
s/he is the only competent member of a group. Such people are often Control
Freaks who use the talents of others
to advance socially or monetarily. There are control freaks and there are
gifted people.
Control Freaks are  a bit like a Prima Dona without the talent.

A control freak joins teams simply to garner status and acclaim. Resume
padding. Or in more advanced cases the goal is to acquire the IPR's.
Team projects do not often succeed because of conflicts between aspiring
control freaks.
The way Boeing worked on the 747 development seems a marvel or high note of
co-operation.
Perhaps Lockheed had it right by developing the Skunk Works system
deliberately excluding
most managers but very extreme.
The ethics are an entirely different issue.

vib





-----Original Message-----
From: Friam [mailto:[hidden email]] On Behalf Of Marcus Daniels
Sent: July-18-15 9:05 AM
To: The Friday Morning Applied Complexity Coffee Group
Subject: Re: [FRIAM] speculative Q


"But the point I was trying to make with those 3 articles still stands: that
people who join communities for community's sake are not necessarily only
drags on, disrupters of the system.  They provide something like a dampening
baffle that traps and eliminates the noise of the extremists, the purposeful
missionaries.  In fact, without _enough_ of that sort of "middling" or
"joiner", a project is more at risk when/if extremists fail to cohere.  And
I think this is true in open source projects as well as proprietary ones."

Right, but from the missionary's point of view, the truth is out there, and
if one project dies another will fill its place..  It is the truth that
matters.

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


============================================================
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