Category Archives: standards

Google’s Cloud Source Repository … WTF :)

1 Reply

So Google has released a beta for  “Cloud Source Repositories” as part of their Cloud Platform.    At first blush it looks analogous to github, bitkeeper, sourceforge, etc. etc.   My reaction to this amuses me.

  • Does Google’s left hand know what it’s right hand is doing?
  • Is this more proof of how a modern high tech company balances trust v.s. velocity?
  • Is this a sign that all the cloud OS vendors will discover that source control is just a feature?

 

It’s painfully ironic that this new thing comes out only shortly after Google murdered Google Code.  It’s really hard to trust a vendor that kills product offerings (i.e. Google Reader, Google Code, etc.).  I suspect most developers are bewildered that they didn’t “just” migrate the Google code users to this new thing.   It really suggests that the team that shut down Google code was entirely independent from the one that build this thing.

There is a B-School narrative about how firms need to balance providing backward compatibility against the need to force their installed base to adopt new technology.  The first is necessary because customers need to trust that their investment in your offerings won’t suddenly depreciate as you create new versions.   The second is because old tech can quickly become a legacy tarpit that enables upstart competitors to leave you in the dust.

Microsoft was good at the first and very slow about the second.  And this dialectic is the primary cause of angst at Microsoft – and has been for about a decade plus.  When you are a monopoly you can spend a very long time resolving these tensions.    The unbelievably long road they took to get to an OS with a reasonable GUI is an example of that, though most people have forgotten that era.

So the B-School narrative around this suggests that a monopoly, i.e. a firm how’s customers are locked in (aka very loyal) can be extremely slow to offer the cool new thing.  That story is changing though.  If the velocity of high tech change increases firms are forced to be more aggressive about chasing it’s tail lights.

Google is willing  to abandon customers more casually than I’d expect.    Well until I recall the last paragraph.  Maybe.

In Google’s case I tend to think it’s more about the culture.  They cough up these products like Google Reader and Google Plus and Google Code and then the team and management loses interest or switch jobs.  The shiny new thing catches their eye.  Maybe they reward new to excess.

Anyhow what ever.

My third take on this is more interesting to me.  I remain fascinated by this new species of operating systems.

The set of things that make up an OS is much larger than they teach you in school.  It’s not just device drivers, and resource management.  These days it’s package management, app stores, developer tools and networks, evangelism, partner management, etc. etc.

Back in the 80s VC would sometimes utter the damning phrase “Oh that’s just a feature.”  For example somebody would author an amazingly complex package that would check grammar in documents.  “Just a feature.”   What that meant was that some other product Microsoft Word for example would swallow that feature.  And sure enough that is exactly what would happen.  Painfully – because each and every time the feature implementation inside the product that swallowed it would suck compared to the stand alone product’s.

So one thing I’m thinking is that cloud based source control (bug tracking, wiki, build tools, etc. etc.) is just a feature.  That it will be swallowed by the cloud platforms.  This morning that seems pretty damn inevitable.

The term platform has always been intended to suggest a stable surface you can build on.  But really these folks come from California.  Earthquakes!

Premature Standardization

Leave a reply

Back in the day I was quite interested in Industrial Standardization.  It’s a fascinating complement to the more widely discussed business models intended to capture and own a given market.

This morning I’m aroused by word that the ISO is working on standardizing how we test software.  My reaction is “Argh!  Surely you jest!”

A few more reactions.

In all my reading about standards I don’t recall a good check list to help guide when to transition a body of practice into a standard.  There is an excellent list of what drives standardization.  But that’s more about the intensity of the demand, not the quality of the supply of professional knowledge.

There are a few good discussions of failure syndromes around standardization.  James Gosling wrote up a nice short one about how often the demand for quality runs ahead of the supply of skills, which I mention here.

There is an excellent model of what goes wrong when you have intense demand for skills, low professional knowledge, and low barriers to entry.   I’ll quote from my post about that:

“The lack of clear quality measures leads the substitution of alternate sources of legitmacy: pomp, pompous attitude, parasitizing on other sources of authority, advertising, character defamation. (A point which deserves a blog posting of it’s own, but since that’s unlikely I’ll toss in this marvelous line. When this happens you see a pattern: consumers hold the trade in very low esteem but hold their personal practitioner in the highest regard. Where have I heard that before?)”

The effort to standardize software testing came to my attention via Laurent Bossavit’s twitter stream.   Laurent has spent a lot of calories on the puzzle of good software development practices.  You should read his book “The Leprechauns of Software Engineering: How folklore turns into fact and what to do about it.”

And maybe you should sign the petition that attempts to slowdown this attempt to prematurely standardize software testing.   Just because we want to have high quality testing practices, skills, and standards does not mean we are ready to write down standards for how to fulfill that desire.  We aren’t ready.

Ray Dolby’s business model

Leave a reply

8trackI read Ray Dolby’s obituary in the New York Times because the Dolby noise reduction system is a textbook example of a two sided network business model.  Invented in the early 60’s the system enabled you to get better audio quality out of recorded sound.  It transformed the audio signal to route around flaws in the tape, tape heads, and transport mechanisms.  The problem it solved grew quite severe when cassette tapes became popular.  To get the benefit a lot of parties along the supply chain needed to play along.  Two in particular.  The companies that manufactured cassette players and the companies the manufactured the cassettes containing the entertainment.

DOLBY_Product_header-NOKIA-N8The obituary get’s it wrong.  Dolby’s achievement wasn’t the signal processing algorithms; his achievement was getting all the players to sign onto his system.  Two-sided networks (standards) are all about the difficulty of attracting, coordinating, and locking-in two diffuse groups.  Dolby managed to own a standard.  And so he got to charge a toll for his small part in intermediating between sound producers and consumers.  .  He them managed to steward that role so that even today his company (DLB) stands at the center of the standardization of sound.  Next time your watching a DVD notice how right there in the credits the Dolby name will appear.  Think about how much time and space that credit takes v.s. other contributors.  And today, it’s all digital!

I wonder if any of the New York Time’s obits talk about the deceased’s business model.

Hourly Cost of Healthcare?

Leave a reply

When you see a gas station with cheap gas are you actually observing?   Consider for example a gas station owner who hires people to pump his gas.  His costs are lower if he can skip providing health coverage.  Examples like that are one reason I support universal provision of healthcare is the powerful way that market competition works to eliminate it.  It’s an ethical puzzle, eh?

The national minimum wage is $7.25/hour, while spend $6,815 per person on health care.  If we presume a 40 hour work week, 52 weeks a year, that’s $3.40/hour.   Or to look at it another average premium for health insurance is $215/month, e.g. $1.29 an hour.

Setting standards, for things like provision of healthcare is one way to address the problems ethical and otherwise that market’s present.   But standards come in many forms, for example labeling.  Maybe the gas stations that have uninsured employees could be required to display a large shaming sign.  Or if you into techno-utopian solutions maybe we could spin up an App for your phone that let’s you look this info up.

The Times has an article today about how the people who pick our vegetables lack health insurance and providing it might cost a dollar an hour.  Well yeah.

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.

Heroku Buildpacks

1 Reply

buildpacks

Heroku is a cloud computing platform, i.e. a place where you can run your applications.  When you author an application on Heroku it is split into two parts.  One part, the buildpack, is responsible for building your application; while the other part is the actual application’s sources.

I found this interesting.  Modularity always serves to separate concerns.  What concerns, and who’s concerns, are natural next questions.  Buildpacks make it easier to get started with Heroku; so they address one of Heroku’s concerns – i.e. “How can we get people to use our product.” – by lowering the barrier to entry.

There are many buildpacks.  Heroku provides a half dozen, and other people have build a few hundred more.  Each build packs makes it easier to get an app based on some programming framework started.  For example there are ones for: ruby, node.js, erlang, wordpress, common lisp, go, etc. etc. etc.

Of course how exactly any given application get’s built tends to quickly become unique.  I suspect that most serious app developers customize their buildpacks.  Heroku makes extensive use of git to move things around, so naturally a lot of the buildpacks are on github.  I got thinking it would be interesting to look at some statistics about them.

The chart above has one dot for each of N buildpacks (in some cases multiple buildpacks have landed on the same dot).  Notice that the chart is log-log.   The vertical axis indicates how many +1 like stars the buildapp has received – so that’s a proxy for how popular it is.  The horizontal axis shows how often the buildapp has been forked.

In one’s fantasy the perfect build app for a given programming platform would fufill all the needs of it’s app developers.  In that case it would never need to be forked.  But three things work against that fantasy.  First off the buildapps aren’t perfect, in fact they tend to simplistic because their short-term goal is to make it trival to get started.  Secondly – I think – the building of applications tends to sport all kinds of unique special cases.  And finally the usual third reason – it’s hard work to push patches around, so even if you improve a given buildpack the chances your enhancments flow back to the master buildpack are – well – iffy.

Anyhow, I wanted to share the picture. (oh, and zero was mapped to .1)

Trust and Crime

Leave a reply

The following framework for thinking about crime, or the breakdown of trust, is excellent:

“Trust is what stands between individual actors and defection (as in the Prisoners’ Dilemma game); between civilisation and anarchy. Trust relates to the risks we must take and the relationships we must establish and maintain to promote sufficiently high rates of cooperation and low rates of defection or cheating for the society to hold together, whether a cycling club or the Roman Empire. Trust can be intimate – as within families – or impersonal, as where I trust the new contractor servicing my gas heating because I trust the certification and monitoring system that causes him to respect safety standards.

The issues to which trust, cooperation and defection pertain are defined as societal dilemmas, pitting actors in conflicting, competing or collaborating relationships. These are often ‘wicked’ issues, and many universal (like the Tragedy of the Commons). Well thought-out examples pepper the book, from price-setting/fixing among sandwich makers or industrial cartels, to bank misbehaviour, overfishing, military desertion, littering, adultery and volume crimes like burglary. These are neatly and consistently presented as tables which (adapted from p131):

  • Identify the dilemma (e.g. Doping in professional sports)
  • Identify the society (All the athletes in the sport)
  • Identify the group interest (A safe and fair sport) and group norm (Don’t take performance-enhancing drugs)
  • Identify the competing interest (Winning and making money) and corresponding defection (Take performance-enhancing drugs)

The analysis continues by describing the trust mechanisms available to the society in question to encourage people and corporations to act in the wider group interest. These come under four categories comprising the fundamental and universal ways whereby societies hold themselves together. The example continues:

  • Moral (e.g. guilt at not winning fair-and-square; shame at failing as role model)
  • Reputational (e.g. keep fans and commercial advertising opportunities by maintaining reputation of a fair player)
  • Institutional (e.g. civil or criminal bans on performance-enhancing drugs)
  • Security (e.g. testing for specific drugs)

The Institutional approach lies at the heart of defining certain behaviours in response to certain societal dilemmas, as  criminal  rather than merely defecting.”

That’s from a book review  of amusingly titled: “Liars and Outliers.”    I guess I’ll need to read the book now; because that applies to a lot of situations.

Why Google’s Troubles Run Deep

Leave a reply

This may be the only thing (archive.org) I’ve ever read that made me actually want to work at Google.  First off, ignore the stupid framing and scroll down to the actual content.
Let me pick some quotes.

Writing about Amazon: “Organizing into services taught teams not to trust each other in most of the same ways they’re not supposed to trust external developers”

Or writing about a fundamental truth: “Accessibility has an evil twin who, jilted by the unbalanced affection displayed by their parents in their youth, has grown into an equally powerful Arch-Nemesis (yes, there’s more than one nemesis to accessibility) named Security. And boy howdy are the two ever at odds.”

But then getting to Google’s deepest fundamental tragic flaw: “one last thing that Google doesn’t do well is Platforms” … “product is useless without a platform”  …  “.Google+ team took a look at the aftermarket and said: “Gosh, it looks like we need some … Let’s go contract someone to, um, write some… for us.”  … “Any teams that have successfully internalized the notion that they should be externally programmable platforms from the ground up are underdogs” … “The problem is that we’re a Product Company…”

ok, nevermind.  But,  I think it’s shockingly exactly right and in the long run it’s not a bad reason to short Google.

If I’ve peak’d your interest read the whole thing (see archive.org now)

I suspect this says something about  Hal Varian’s status in the senior leadership.  I presume he understands this.  But maybe not how fundamental it is.