Category Archives: open source

Precarious: freedom’s just another word for nothing left to lose

3 Replies

I am watching with great interest the emerging backlash to open systems and sharing economies and I support it.  It’s going to be subtle to assemble a workable framework for this backlash.  Like fire or light or honesty the open/sharing movement has so much good to say for it.  A potent populist appeal is always nice, and it has that too.  But this is not working out well.

… the ‘sharing economy’ has shown itself to be overwhelmingly an anti-regulatory, precariat-creating way of monetizing social interactions. The term has been so exploited by some of the most vile, greedy technolibertarians around that it is time for me to write off more than a decade’s work. …

Amen brother.

Google’s Enclosure of Android

Leave a reply

steampunk_andoid_caseI do like Ars Technica.

I while back Ars Technica wrote an article about Google’s Play Services on the Android.  They treated Play Services as the solution to a problem, i.e. getting updates to the phone. Carriers, hardware vendors, and users all make this hard.  Platform vendors often run into the problem that their installed base becomes immovable.  Play Services routes around these guys, it has its own update path.  Ars Technica even went so far as to suggest Google might not need to make Android OS releases as often.

At the time I disappointed.  They didn’t seem to recognize how this was really about moving Android from Open Source to proprietary. Well, this new article certainly fixed that! Now they get it.

Google is doing an amazing job of locking down the actors the complement this business. They are gaining control of the users, the hardware vendors, the carriers, and the app developers.  If you do business architecture around Open Source you need to understand this stuff!  The article is a handbook for how to enclose an open source project.

Did they plan this?  Or did it just emerged organically from the nature of the business?  I’d love to know the people who can do the former, but the latter is much easier on one’s conscience.

Leave a reply

Luis writes:

Open source and open standards are similar because both are generally created by communities of collaborators who must trust each other across organizational boundaries. This is relevant to the right to fork, because the “right to fork” is an important mechanism to help those communities trust each other. This is surprising – the right to fork is often viewed as an anti-social right, which allows someone to stomp their feet and walk away. However, it is also pro-social: because it makes it impossible for any one person or organization to become a single point of failure. This is particularly important where the community is in large part a volunteer one, and where a single point of failure is widely perceived to have actually failed in the past.

Which is a nice way to frame things.  I particularly like the phrase “trust across organizational boundaries.”  It’s a phrase that get used in interesting contexts.  My fellow open source enthusiasts tend to thing that the trust problem is between individuals, but in the end individuals are just tiny organizations.

The phrase “single point of failure” is an interesting way to frame the larger problem of contingency plans.  Yeah!   Right to fork is a kind of prenup.

Open Reader API

Leave a reply

I use Vienna as my RSS feed reading.  The new beta release is interesting.  A while back Vienna added support to pull your feeds from Google Reader.  I never used that, i pull each feed directly from the source.  I didn’t use it for three reasons: 1) while I read blogs on multiple devices I partitioned the blogs per-device; 2) I never got around to it; and 3) I don’t really like the idea of an intermediary knowing all the blogs I read.

The new release has support for pulling feeds from other sources.  And I’m delighted to see that there is some hope that we will see an open standard emerge for the aggregation service’s API; along with open implementations of that.

In turn this would help to allow more privacy around the aggregation service.  That’s a hard problem, but I have a sketch of a possible solution.

Caesar’s Render

Leave a reply

ceaserJohn Siracusa has posted a quite thought provoking piece about the power games unfolding between Google, Apple, Facebook and others.  Let’s say you wanted to own a cirtical open source project, i.e. own a key standard.  How might you go about that.  He makes a case, that has some merit(sic), that contribution rates can be used by a firm to buy control of an open source project.  If so, then it’s only a matter of money and time.

It’s a good essay and worth reading.  In my limited experience firms are rarely this strategic; but in retrospect they can stumble into outcomes like these – moving fast, hill climbing, and a bit of impatient greed can goes a long way.  But, yeah – who knows … he might be right.

Searching for Alternate Routes

1 Reply

RNA viruses may well be the ultimate r-selected species.  The life cycle of an RNA virus includes a few steps.  Infecting the cell, coopting the machinery of the cell, making copies of its self, assemble those copies into viral particles.  Then the offspring need to escaping the cell, avoid the immune system, and find a new cell to infect.  If it’s that simple then it’s seven steps.

I very much doubt it’s that simple.  In fact the illustration above shows just the bit where the virus enters the cell and off it’s coat.  There is an antiviral drug that works by frustrating it’s attempt shed it’s coat.  Obviously it get’s even more complex yet again if we add in how the virus moves between host animals.

But the copy step is notable. In quantity and quality.

a typical RNA viral genome of 10,000 bases, a mutation frequency of 1 in 10,000 corresponds to an average of 1 mutation in every replicated genome. If a single cell infected with poliovirus produces 10,000 new virus particles, this error rate means that in theory, about 10,000 new viral mutants have been produced.

The quantity is high, but the quality is low.  Amazingly there is method in this madness.  The combination of high errors and high numbers creates something useful, a search scheme.

If you want to frustrate a virus then you need to shutdown, or a least narrow, the pathway through which one of the steps in the reproductive cycle.  For example, improved hygiene and increasing social distancing works by making the movement between host animals harder.  Anti-viral drugs target individual steps in the cycle.  The immune system learns to recognize the virus and pick it off as it moves between cells.  In all these case the challenge for the virus is to route around the resulting bottleneck.

Since most of it’s offspring are mutants, most of it’s offspring are sacrificed to searching for these alternate pathways.  Like most r-selected reproductive strategies the vast majority of the offspring fail in the process.  When the spider has a thousand babies it works out because takes that many to searches opportune door into the next cycle of reproduction.  When the maple tree throws off billions of seeds during it’s life that works because it needs to run that many searches to find one that let’s it pass it’s genes into the next generation.

It must be vary frustrating for the inventor of an anti-viral.  The stupid viruses can mindlessly find a route around his clever invention.  Adamantine was approved for use in 1966, by the 2005-2006 US flu widespread flu strains had routed around the hole it plugged.  I think we can assume that the route around was found quickly and what took most of the time was propogating it around the larger community of flu viruses.

There are interesting analogies to be drawn between this and the way we use r-selected designs in open source, platform, social-network, strategies.  I need to stew on that.

As with most things these days, I draw analogies twix this and my job search.  I keep trying to have the options be numerous and to try to treat the failed attempts casually.  But my species is not naturally given to r-selected tactics.

Git

1 Reply

I’m really blown away by how nice a bit-o-work git is.

What Eric von Hippel taught me works both ways.  Real innovation requires close contact between a interesting problem and talent.  When you encounter innovation it signals an interesting problem and engaged talent.  Ignore the story told.  Look for that problem and why the talent had to fix it.  Ask, without the snark: “so what’s his problem?”

It’s a guess, but I think Linus’ problem was two fold.  First was a deep passionate desperate need to encourage other developers to take risks with the code.  I think his guilty foxy phrase for this is: “They do the work so I can take the credit.”  He wants to encourage forking!  That’s obvious, once I recognized it.  But it’s an insight that was denied me because forking has such a bad reputation.  I knew a guy once.  He forked, later he had a nervous breakdown trying to rejoin the main branch.    An exagerated story sure, but I have suffered dozens of cases where-in good labor branched off and nothing came back.    So given those experiances the insight that forking is something an Open Source project would want to encourage, v.s. temper, has left me gob smacked.

But it’s absolutely true.  To suppress forking is scarcity thinking.  Inside a closed system where you need to husband resources in an open system you need to court it.  I know that, I just didn’t get it!  Almost the whole point of open source is to cast forth the code so a million eyes and hands can improve it.  And every one of those improvements will be a fork.  It would be insane to try and keep that from happening.  If you don’t enable billions of tiny edits/forks then your killing the seed corn.  Since the entire cascade starts there (and it’s scale free) failure to encourage forking undermines the flow back toward the main branch(s).

I didn’t see that, at first.  I came to that in a round about way.  And damn if I did not have to puzzle out the second insight in a really round about way.  I’m embaressed to admit I was not trying to figure out what “his problem” is.  No, I was confused by this scenario that appears in most of the tutorials.

Your working on some complex change and suddenly your Boss steps into the room and demands a quick bug fix.  What do you do?

... working on complex change ...
git checkout deployed_version
... make quick fix ...
git checkout branch_of_complex_change
... back to work ...

My reaction to that was “Huh, what? you don’t got any diskspace?”  Just check out the main branch into a fresh directory and do the work there.  In fact I’d be surprised if you didn’t already have a copy checked out.  So it took me a while to accept the shocking part was that switching between branches in the same working directory is a common operation.  It was only then that I asked “why would Linus want that?”  That was the “what’s his problem” moment.

This story is a lie.  Linus doesn’t have a boss like the one in that story.  Linus lives on the boundry between “they do the work” and “i take the credit.”  His boss, and this is critical, is “they.”  “They” burst into his virtual office and make demands; in the form of patches.  Each of those demands/patches is branch.  Managing them is Linus’s problem.  At any given time you might have a hundred, thousands even, of such demands/branches.  It’s not your Boss coming thru the door that triggers switching from one branch to another; it’s email, irc, and the whims of your attention that do it.  When ever your brain thinks “Oh, I wonder if patch Foo does Bar?” you do git checkout Foo, look into the Bar question.  A moment later, buffeted by another boss/demand/patch you switch off to another branch.

These two are complementary.  That git encourages forking energizes the periphery of your project; that it empowers you to manage a blizzard of patches lets you deal with the consequences.  But even if you don’t need to have a vast army of contributors I find that rapid context switching useful.  My damn brain is full of contributors too.  I can give all these fever’d demons their own branch.    You can cast those hot ideas out of your head an into git, stew them over time.  It maybe a chaotic mess, but git provides the tools to help manage all that.

While this is a totally different model of branching and forking from the one in traditional source control systems, it is absolutely better.  It is better at assuring the improvements are enabled, captured, managed, and nurtured.  Full stop.

There is a social aspect to git that deserved it’s own posting.  But leave it to say that it’s actually brilliant, from the point of view of somebody more familiar with the ASF’s development models, because it enables and encourage the forming of small groups of common interest around forks.  Brilliant because it’s scale free.  Brilliant because it creates a locus for socially constructed validation tied to that common interest.  Brilliant because it distills out the flow of commits in a canonical form that enables the forks to bud off and remerge smoothly.  Brilliant because it removes a huge “ask permission” cost; i.e. in this system you don’t submit patches you mearly reveal them.  Notice that word “submit.”

I wrote an essay years ago about what could be done to improve the dynamism of open source.  I wrote that there was a virtous cycle between the code base and the user/developers and one thing that we seriously needed was to look at all the friction in that cycle and see if better tooling and practices couldn’t ease them.  Git delivers!

The No Carrot, No Stick Zone

Leave a reply

This talk by Clay Shirky is a basicly the first bit of his book performed live.

He cut from the book the suggestion that the phase transition we are going thru is going to lead to chaos.

I don’t recall hearing before the delightful idea that Institution rely of carrots and sticks, but that if you want to tap into the the long tail of one off contributors you can’t do that, making the long tail a no carrots, no stick zone. That is very line nice. While it’s probably not true, since systems that work by filtering value out of that thin soup of long tail contributors can to a lot to manage their incentive structures, it is a very good rough approximation of the right mindset.