On Behalf Of

The internet was invented by Vint Cerf.

But it was made usable by Marc Andreeson. And what he did was simple:

He turned it into a VCR.

Now, it seems deeply ironic to me that most of the folks reading this post have probably never used a VCR, although they’ve most certainly used the Back, Forward, Stop and Play buttons on a web browser.

It was a powerful metaphor, and it made it possible for nearly half of the world’s population to grapple with the experience of traversing a directed, cyclic graph.

And in much the same way that we floundered in the world of Gopher and Finger protocols before Marc’s insight of metaphor, we’re floundering in the early world of IoT.

We need a metaphor. And it needs to encapsulate a deceptively difficult concept: - Agency.

Understanding Agency

My refrigerator may someday be able to detect when the cream has gone bad, and order more - either from Amazon, or from some local grocery store delivery.

Quite literally, my fridge will be acting on my behalf - an agent, if you will.

It will authenticate itself with my home wifi network.

And again with the grocery service, with a payment provider, and possibly with an independent shipping or delivery service.

Likely, though, the software that actually orders the milk, won’t be running on my fridge. Instead, it will be cloud-based, and acting on behalf of my fridge, which is in turn acting on behalf of myself.

In Search of a Metaphor

When I was young, I worked as an apprentice carpenter. Often, this included errands to the local hardware or lumber supply store. And usually, I was equipped for these errands with my boss’s credit card (as well as his truck).

Strictly speaking, proffering someone else’s credit card (and signing for it) is illegal, much the same as sharing the password or pin to your bank account. And yet, the image of a household robot, with an empty milk jug in one mechanical hand and a credit card in the other, is the best metaphor for delegated authentication that I can come up with. And it’s simply not good enough.


Where in the world is Joshua McKenty?

  • October 6: SF
  • October 13: Victoria
  • October 20: Korea and SF
  • October 27: Victoria
  • November 3: Paris and NYC
  • November 10: Victoria
  • November 17: LA and Denver
  • November 24: Victoria / SF
  • December 1: Arizona
  • December 8: Victoria
  • December 15: Toronto, NYC, SF
  • December 22: Victoria
  • December 29: SF
  • Jan 5: Victoria
  • Jan 12: DC, Atlanta, Kansas City
  • Jan 19: Victoria, Vancouver
  • Jan 26: SF, Detroit, Tampa,
  • Feb 2: Victoria, NYC
  • Feb 9: Victoria, SF
  • Feb 16: Victoria, SF
  • Feb 23: DC, NYC, SF
  • Mar 2: Austin
  • Mar 9: Banff, DC, SF
  • Mar 16: Victoria, Vancouver
  • Mar 23: Victoria, Seattle
  • Mar 30: Victoria
  • Apr 6: DC, Cincinnati, Seattle, SF
  • Apr 13: Victoria, SF
  • Apr 20: Victoria
  • Apr 27: LA, SF
  • May 4: Victoria


tldr: Use equity warrants for open source trademark licenses.

Long Version:

Apache Software License v2.0 allows the free and unrestricted use, modification, and what-have-you of the source code. However, it protects the use of the name and brand of an open source project.

In the OpenStack world, we license this brand to vendors who agree to follow a trademark license agreement that includes, among other things:

  • Paying to be a corporate sponsor or member of the OpenStack Foundation.
  • Using certain, unmodified sections of the open source code.
  • Passing a compatibility test suite for functionality of all public APIs.

But we could have gone one step better.

Imagine a trademark license where, along with cash and compatibility, the open source entity also received a small amount of equity in the licensing firm.

This would make the owner of the trademark, rather than being a non-profit foundation, a Public Benefit Corporation.

The stated public benefit purpose could guarantee that the source code license and trademark policy would not be changed.

And the equity stake would guarantee that this company would have the motivation to improve and enhance the open source code to meet the needs of all the licensees.

Keeping the core development teams “in-house”, so to speak.

While also being able to motivate these “best-and-brightest” through stock-options, and a potentially lucrative future.


  • Does this make the B-corp a “hedge fund” or some other entity?
  • Would the trademark license need to be baked into the bylaws of the b-corp for reasonable protection?
  • Could standard ISA stock options work for this?


  • Yes, this means I’m not a fan of the “everyone-contributes-and-scratches-their-own-itch” model of open source development. While I think that’s helpful for modules, plugins, and niche features, I think open source projects are best served by dedicated, core development teams. See Mozilla, Wordpress, Android, and Drupal for examples of this.
    • Yes, this means that there can be a large community of “vendors” that are attacking the many go-to-market models which might logically exist for a single open source project. It’s like genetic algorithms - but for business. And the core open source organization benefits, regardless of which ones are successful.

block chain

Trying to understand the ecosystem of “Proof of Luck” based distributed systems.

Use observable phenomenon to time things: - http://arxiv.org/abs/1311.3693 - http://en.wikipedia.org/wiki/Pulsar#Precise_clocks

Use fancy algorithms: - http://pagesperso-systeme.lip6.fr/Marc.Shapiro/papers/RR-6956.pdf - http://highscalability.com/blog/2010/12/23/paper-crdts-consistency-without-concurrency-control.html - http://www.commsp.ee.ic.ac.uk/~mandic/dvv/papers/physica%20D.pdf

The Dead Pool Pledge

I love PaaS. Recently I’ve gone to great lengths to figure out a way to build applications using ONLY SaaS and PaaS platforms. I managed this with a mix of wercker, github, orchestrate.io and pivotal web services.

But with the commitment to any third-party platform, comes a certain kind of fear.

I’m a believer in open source. And I’m ALSO a believer in commercial software. As much as I believe in the rights and freedoms of the user, I also value the rights and freedoms of the developer - to license his or her work in the way that they see fit.

So here’s what I’m suggesting: a “Dead Pool Pledge”.

Add this github account to your private repositories as a collaborator. You can keep those accounts private, and your source code licensed under whatever terms you feel is appropriate, as long as your business/project/coop is a going concern.

But the day that your company ends up in the Crunchbase deadpool, my bot will republish your source code under ASLv2. Seem fair?

I know that if Wercker, Orchestrate.io and others adopted this, I would sleep a little better at night.


Okay, maybe we should try and contact you first - to find out if you’re attempting to sell off those assets to a company who has a legitimate intent to continue business operations.

And yes, this whole thing probably ought to have some sort of contract in place - maybe something that the SFLC or the EFF could draft up.



Most of my projects fall within a few main themes:


Browser Things

Social Infrastructure


  • Build packs for Cloud Foundry and steps for Wercker.
  • AfterStack.com : Haven’t decided what this is yet ;)

Defunct Projects

  • BountyUp.com : Like Kickstarter, but 5 years too early. Frozen by the SEC.
  • BuyLatr.com : Browser plugin for price change notifications. Sold it.
  • PatchMe.in : Never miss a conference call or dial a stupid conf ID again.

How I Learned to Stop Worrying and Love the (Static) Web

I’m an early fan of the Baked, Not Fried concept behind static web generators. But somehow, getting all the tools in place to run one myself seemed onerous. A simple apt-get install mysql was always easier than the vaguely-mystical incantations required to get jekyll up and running.

Then again, there was my deep-seated prejudice against Ruby. (See my previous trolling of the ruby community when I accused them of being singlehandedly responsible for Global Warming.)

But with the emergence of Hugo, an elegant static site generator written in #Golang, I’ve been able to get over the line. Or maybe it was simply time that I had a blog again.


Joshua McKenty

I work on both open source and commercial software. I can probably attribute this socialist/capitalist mix to my dual American/Canadian citizenship, but I’m not that fond of introspection.

I am a cofounder of OpenStack.

The longer stories have been told repeatedly, but suffice it to say that some mix of Jesse Andrews, Chris C. Kemp, Devin Carlen, Vishvananda Ishaya, Soo Choi, Andy Smith, Manesh Singh and myself ought to be held responsible for the release of “nova”, while we were all affiliated with the NASA Ames Research Center.

I am the cofounder of Piston Cloud Computing, Inc., the first commercial provider of a supported OpenStack software product.

In prior lives, I worked on the Netscape Browser, and the Flock Browser.

I had a brief stint at Tapulous, right around the time of the Apple iPhone App Store launch.

I also founded BountyUp, Natel Canada and BuyLatr, none of which had terribly notable exits.

Most of my open source work is available online on github.


I currently sit as an elected Gold Member director on the OpenStack Foundation Board of Directors. In that capacity, I am the co-chair of the DefCore committee (along with Rob Hirschfeld). I was also the founding chair of the (now-defunct) Transparency Working Group.

I am an appointed member of the Cloud Foundry Advisory Board.

I am also an appointed member of the Open Contrail Advisory Board.

Social Media

I don’t blog all that often.