Capabilities for Open Source Innovation: Background


Organizational Capabilities


Open Innovation




Levels of Engagement








Other Relationships Across Company Boundaries





Technology Innovation and Open Source










Further Reading









Transitions in Open Source Initiative leadership

What we call the beginning is often the end
And to make an end is to make a beginning.
The end is where we start from.
— T.S. Elliot, “Little Gidding”







(Re-posted from:

The Future of Open Source





First Age of Software



Software & Internet Law, 4th Edition, page 31-32




Software & Internet Law, 4th Edition, page 32




Software & Internet Law, 4th Edition, page 32


Middle Age of Software





Software & Internet Law, 4th Edition, page 33



Free As in Freedom (2.0), page 4








Modern Age of Software











What Lies Ahead







Engaging hidden influencers as active participants

Shared Intro: After the summit (#afterstack), a few of us compared notes and found a common theme in an underserved but critical part of the OpenStack community.  Sean Roberts, Allison Randal, and Rob Hirschfeld committed to expand our discussion to the broader community.  Instead of sharing a single post, we wanted to bring our individual perspectives to you and start a dialog. See Rob’s post and Sean’s post.

Historically, open source projects have focused on developers as individuals, applying a kind of social filter to their corporate affiliations. And historically, this was the right approach to take. Those of us who have been around a while have collected far too many old stories of companies that tried to control open source projects rather than beneficially participating. Downplaying the companies behind the developers was an effective way to channel their contributions through a sanity filter.

But, there’s another dimension that few open source projects acknowledge, which Rob Hirschfeld has aptly dubbed “hidden influencers”. I encountered it at Canonical, and now at HP: developers don’t operate in a vacuum, and their success or failure at contributing to open source projects depends heavily on the support (or lack of support) they receive from the management context they operate in. This is true for independent developers — whatever day job they have to pay the bills may not understand why they spend their nights and weekends on volunteer development. (Many of my employers have understood, and I have always felt lucky that they do.)

Support from management has an even greater impact on developers who work on open source as their primary job.

Some people might see that as a bad thing, but I don’t. I can tell you from experience at Canonical and HP that a manager or executive who understands open source (possibly even has experience doing open source development) is a powerful force for good in an open source project. Unlocking the power of those hidden influencers is a unique opportunity, and very few open source projects are effectively taking advantage of it.

As I’ve talked with managers at HP and other companies around OpenStack, it impresses me that the vast majority who have OpenStack core reviewers or PTLs on their team are actively enthusiastic about their developers’ work and success within the project. I saw a number of these managers at the Summit in Atlanta. But you probably didn’t see them or talk to them.

Are these managers hiding?  Not exactly.  They are all over:

  • Design Summit:  Those sessions are geared toward developers.
  • General session: Those sessions are geared toward users and operators.
  • Developer’s lounge
  • Hallways: This informal “track” is the main place where you’ll see managers interacting.

But there really isn’t any forum for managers to interact around the kinds of topics that fill their daily task lists.  So what would have been valuable in cross-company management communication?

  • Allocating developers’ time to deliver the features discussed.
  • Sharing workloads across developers in multiple companies, and avoiding duplicated efforts.
  • Balancing internal delivery commitments with external delivery commitments.
  • Growing new contributors, from existing employees and new hires.

I not talking about release management here, OpenStack has a highly effective release management program already in operation. What I’m mostly talking about is people management, though there’s also an element of business strategy around OpenStack.

I’d like to see OpenStack as a project more actively engaging with managers as participants, acknowledging their contributions and building collaboration structures for them. Done right, this could set a strong positive example for future open source projects, blaze a new path for guiding beneficial corporate contribution, above and beyond trying to ignore them. Let’s start by simply talking with managers of OpenStack contributors at a variety of companies, finding out where their pain points are and what kind of collaboration would be most beneficial to them.

Relativity, skepticism, and virtual worlds

Yesterday on Twitter I posted:

Has anyone applied Einstein’s theory of relativity to radical skepticism? i.e. spaces of reference in knowledge relative to each other.

Twitter is great for tossing out a quick idea, but on reflection, this one probably needs more explanation. To give credit where credit is due, the idea occurred to me while I was watching a Coursera lecture on Epistemology by Duncan Pritchard (University of Edinburgh) for an evening’s entertainment (what can I say, it’s more fun than most things on television). Though, ultimately, the idea is a distillation of several lines of thought that have been knocking around in my head for years now. (If you really, really want to get at the roots, it all goes back to Richard Jozsa, who was my professor in Quantum Computation at the University of Bristol before he moved on to Cambridge, and who set me on a whole new path of thinking.)

First, a bit of lightweight background, so everyone can follow along. In very rough terms, radical skepticism is a perspective on the fundamental nature of human knowledge, specifically that knowledge is impossible. Pritchard used the classic “brain in a vat” or “Matrix” illustration, which might be simply stated: If I were a brain in a vat, being fed fake experiences by a computer (far more advanced than any we currently have, but still, play along for the sake of argument), then everything I think I know about the universe would actually be fake. I wouldn’t really “know” anything. And the kicker is, there really isn’t any way to prove I’m not a brain in a vat, and therefore, at a very basic level there isn’t any way to prove that anything I know is true. (Apologies to academic philosophers who might happen to read this, I’m keeping the explanation as simple as possible.)

Now, relativity in physics (again, very much simplified) is a theory that examines motion within frames of reference. For an intuitive sense of what this means, go outside and throw a ball to a friend so they can catch it. Now, go ride on a train with the friend and throw a ball there (try not to hit the other passengers). The two situations have radically different external contexts, one is stationary on the sidewalk, the other is hurtling along the tracks. And yet, for you, the friend, and the ball, the motion is the same: if you throw the same way and catch the same way, the arc of the ball relative to the two of you would be the same. The train car forms a frame of reference, and you can meaningfully examine the laws of physics within that frame, while completely ignoring the motion outside the frame. And, of course, remember that even the “stationary” case is actually on a planet that’s spinning and hurtling through space around the sun, in a universe that’s also in constant motion.

(Digression: Years ago, I set out on a lark to memorise the entirety of an English translation of Einstein’s “Spezielle Relativitätstheorie” i.e. “The Theory of Special Relativity” (Doc. 71, Princeton Lectures). I still can’t recite the whole thing verbatim, but a funny thing happened along the way (as I took classes in quantum mechanics and astrophysics): at one point a lightbulb went off and I suddenly realized I wasn’t just memorizing anymore, I was beginning to understand what Einstein was talking about on a deep level.)

Okay, bringing it back around, the problem with radical skepticism is that if you declare that it’s impossible to know anything, then any study of the fundamental nature of human knowledge, philosophy, or ultimately our entire existence, is really rather meaningless. Simply saying “it doesn’t really matter if I’m a brain in a vat” is a shatteringly weak argument in the face of “everything you think you know is wrong”. And yet, the recorded history of humanity demonstrates that it’s possible to construct internally consistent systems of knowledge, and value in exploring the nature of that knowledge. What if, instead of trying to wave away radical skepticism in a puff of smoke, we instead accepted it as a fundamental truth, at the same time as systematizing a study of knowledge within frames of reference, analogous to Cartesian frames of geometry or relativity frames of motion. So, whether I am a brain in a vat, or a living, breathing physical organism experiencing a physical environment, I exist within a “frame of reference” (a computer-constructed or physical world). Within that frame it’s meaningful to study the system of knowledge, while abstracting away from details outside the frame. It’s even meaningful to study the nature of knowledge across different frames of reference, for example as either a brain in a vat or a physical organism I might “know” that I have two hands, that one of them is grasping a cup of coffee, etc, etc. In either frame, I have a true belief, reached through the reasonable application of my cognitive abilities. My knowledge of my hand and my knowledge of the coffee cup are the same relative to each other, within both frames of reference. In a sense, we can say that the “laws of knowledge” are consistent across frames of reference.

Let’s take it one step further. When I inhabit a virtual world, whether it’s as vast and mutable as Minecraft, or as carefully controlled as a game in the Zelda series, I enter into a frame of reference of knowledge. I become a “brain in a vat” to that virtual world, because my dual existence as a physical organism in a physical world isn’t relevant within that frame. This is only becoming more true as technologies like Emotiv’s EPOC controller begin to make the brain-to-world connection more direct, and technologies like Oculus Rift begin to make the world-to-brain connection more direct. Within the frame of reference of a virtual world, I may have genuine knowledge that I have two hands, and that one of them is holding an object. As a slightly more abstract but still narrow example, I may have knowledge of completely different physical laws in two frames of reference (one may not have gravity, or may permit me to fall from 1,000 feet without injury), and yet both have an internally consistent set of physical laws, and my knowledge of those physical laws is absolutely essential to my ability to function as an entity within that frame of reference. And, I can meaningfully compare the nature of my knowledge of physical laws across the two frames of reference, even though the physical laws themselves are different. So frames of reference in knowledge aren’t merely an academic abstraction for the sake of reconciling two apparently conflicting approaches to philosophy. They’re also potentially a valuable tool in the study of the fundamental nature of human knowledge, in much the same way that relativity was to physics.

BTW, if anyone knows of research or published articles heading in this general direction of thought, I’d be very interested to hear/read more about it.

Mythbusters – Why I (still) Love Perl

At the very beginning, I should probably make it clear that this post is not a declaration of exclusivity in my relationship to Perl. I love programming languages. I first learned to program about the same time I first learned to read (English) and first studied French. My love for programming languages is very much akin (and I swear linked to the same part of my brain) as my love for human languages: they are all unique and beautiful in their own way. I love Python, I love C, I love Smalltalk, I love Erlang, etc, etc.

But Perl has taken an entirely undeserved beating in recent years, and so, in karmic balance, it deserves a round of outspoken championship, far more than others need right now. In pondering why Perl’s current reputation is so completely disjointed from the reality of the language, I’ve boiled it down to three “Big Bang Theory”-esque ideas: “The Cookie Slap! Effect”, “The Awkward Adolescence Fallacy”, and “The Singularity Paradox”.

The Cookie Slap! Effect

There’s a “Perl is Dead” meme floating around. It’s been around for a while, long enough that it’s picked up steam and plows along despite all evidence to the contrary. It’s so common, I won’t bother providing links, because you’ve seen more of them than I can count. It’s so common, I even heard it recently from a young MBA graduate, who was so entirely non-technical that he didn’t even know what HTML and CSS were, while working in sales for a web startup. But, he knew what Perl was, and he “knew” it was dead. Weird, but that’s how memes work. So, how did this meme start?

There’s a well-known gaming scenario often called “King of the Hill”, where one player has special status, and the goal of all the other players is to knock that player out of the privileged position and take it for themselves. There was a time when Perl owned the web. It was the duct tape that built the “Web 1.0 City”. There are a number of reasons why Perl succeeded so wildly, but most of them boil down to being in the right place, at the right time, with a fresh, dynamic take on what “programming” should be like, and what “programmers” should be like. There are many things that C excels at, but manipulating massive, variable-length strings is certainly not one of them. And, at the end of the day, no matter what abstractions you layer on it, Web development is essentially about dynamically building and pushing out very lengthy strings of HTML and CSS (and Javascript) to browsers that will decide how to render them. C sucked for that. Really sucked. Trust me, I’ve been-there-done-that.

So, Perl dropped into what was effectively an empty space, at a time when the demand for web services was sky-rocketing. Score! And established itself as the King of the Hill. Score! But then, as the dominant player, Perl also became “the one to beat”. Every upstart young programming language compared itself to Perl. “We’re better than Perl because…” And this is where the “Perl is dead” meme started. It was popular to put-down Perl, because Perl was “unbeatable”. Of course, it was never really unbeatable. The chances that any one language would continue to dominate the web are exceedingly tiny, effectively zero. The chances that any one language will ever again achieve the dominance Perl once had are equally tiny. Especially when you consider the fact that diversity is one of the single strongest cultural values of this miraculous, glorious, networked universe we now inhabit. A cultural value that it partially learned, BTW, from Perl’s TMTOWTDI (there’s more than one way to do it).

So, when you hear “Perl is dead”, remember this, the only reason the meme has strength is because Perl itself has strength. No one feels the need to loudly proclaim “Draco is dead”, because really, no one cares. And secondly, remember that at the root, the primary reason for declaring the untruthful “Perl is dead”, rather than the far simpler and truthful “Perl doesn’t have the domain dominance it once had”, is an insecurity about whatever language the speaker happens to love. Perl is an elder-statesman in a closed system. The shocking truth about the Tiobe Index isn’t that Perl has drifted down over the years (languages wax and wane, just look at C), it’s that all of the languages in the top 20 are OLD in technology-years. It’s like looking at Forbes’ list of billionaires from year-to-year: they shift in position, but once someone’s on the list they have an advantage over all the players who aren’t on the list (massive capital to invest in one case, massive numbers of users and lines of working production code in the other), which means they’re likely to stay on the list.

And, if you’ve ever said “Perl is dead”, my advice is to learn a lesson of tolerance, “live and let live”. Perl won’t plow your favorite language under the carpet, it’s not a threat to you, but I also guarantee your favorite language won’t plow Perl under the carpet. The best you can hope for is to be accepted as a member of “The Fellowship of the Languages”, so grant other languages the same respect you’d like to receive from them.

The Awkward Adolescence Fallacy

Around Perl’s 13th birthday, which just happened to also be the fiery heart of the dot-com bust, the child-prodigy suffered from a massive anxiety attack. As the Web 1.0 world went down in flames, the Perl community was quite literally tearing itself apart. There were a variety of factors, layers of complexity as in any human conflict, but one of the key factors was the nagging doubt that creeps into anyone’s head when things aren’t going as well as you’d hoped: “Maybe it’s my fault. Maybe I didn’t deserve success.” That line of thinking is generally not true, or at least wildly exaggerated, and generally not helpful.

One result of this early-life crisis was the birth of the Perl 6 idea, but I’ll punt that to the next section. Another more subtle (but also more powerful) result, was a growing obsession with things not being “good enough”. The calm confidence of Perl’s youth was replaced by fears that the syntax wasn’t good enough, the implementation wasn’t good enough, the community wasn’t good enough, the foundation wasn’t good enough, the license wasn’t good enough…

To a certain extent fear is a healthy thing, it drives you to push harder, to conquer the thing that you fear. And Perl did. The catastrophic flame-wars of the late 90’s were put to rest. The foundation was restructured and strengthened, and is now one of the most professionally run open source foundations I participate in, with solid, steady funding to run projects that are hugely beneficial to Perl. The Artistic 2 license was introduced as an improvement, but even the existing Artistic 1 license proved itself in court, in a way that no other open source license ever has, and in a way that benefited the entire open source community. The syntax, implementation, and libraries of Perl 5 have improved substantially, to the point that working with “Modern Perl” is really a very different experience than the Perl of 10 or 15 years ago, while still retaining the characteristics that make it a joyful language to code in.

But the bad side of that fear was an awkward, shy hesitation. Like a gawky teenager, Perl stood at the side of the room, afraid to dance because people might think he looks funny. So, I’ve got a news flash for you: no language is perfect, no syntax is perfect, no implementation is perfect, no community is perfect, no foundation is perfect, no license is perfect, nothing is perfect. Perl wasn’t perfect when it owned the web. Perfection is not the first step to success, it’s not even a milestone on the path. And if you really want to understand how irrelevant perfection is, pick any random language you admire, that you see as the pinnacle of success, and closely inspect its syntax, implementation, community, foundation, and license. You’ll find it’s flawed. Why? Because we’re all human, and we all produce things that are deeply creative, deeply wonderful, and yes, somewhat flawed.

It’s time for Perl to grow up. It’s not a teenager anymore. It’s time to accept what it is, accept what it isn’t, and walk on. And what it is, is pretty outrageously amazing. I’ve recently had the opportunity to help a wildly successful startup, in a domain that sorely needs the advantages of modern tech. Perl is the right tool for the job. If I explained the problem space you’d agree, even if Perl isn’t your favorite language. Perl is the right tool for a lot of jobs, all over the world, right now, stable and reliable, in production, with massive numbers of lines of code.

The Singularity Paradox

When Perl 6 was announced, it had a wonderful effect on the Perl community. It provided an “event horizon” to focus everyone’s attention on Perl’s future. It was an inspiration for new creativity, and a distraction from the flamewars to help kill them off. But over time, some things happened that we entirely didn’t expect. The most obvious is that it has taken rather longer that we anticipated. I remember a time when “6 months” was a completely reasonable project estimate for the Perl 6 production release. (Not “By Christmas”, but a real, project-planning 6 months, where I could map out what needed to happen each month.) 13 years later, that clearly didn’t happen. But the time factor is actually a side-effect of other things we didn’t anticipate. The single biggest thing we didn’t anticipate is that the “community rewrite of Perl” has, in fact, turned out to be a community fork. Perl 6 is not like Python 3, which really is a continuation of Python 2, with the same developers, same users, and same community values. (Sometime I’ll write about my interest and contributions toward the Python 3 migration effort, with its own unique successes and challenges.) What grew out of the Perl 6 idea is a new community, a new group of developers, and even a new identity, “Rakudo” rather than Perl (with a phase of “Pugs” along the way). The core Perl developers still work on Perl 5, and have little or no interest in Rakudo. Some of the Rakudo developers have a background in Perl, but many of them have a background in PHP, Java, C#, or other languages.

Rakudo is not an “upgrade” from Perl. It’s revolutionary and exciting, just like Perl was in 1987, but it is not Perl. Please note that I’m not commenting on the similarity or difference of syntax between Perl and Rakudo. If you take a long view over the history of programming languages, syntax is about as relevant to the success of a language as the color of the bike shed. And if you really, really get down to the nuts and bolts, the syntax and functionality of Perl, Python, Ruby, PHP, and Lua are all fundamentally quite similar. That doesn’t make them the same language, and more importantly it doesn’t make them the same community.

So, we stepped into Perl 6 expecting the full power of the mighty Perl community pushing it forward. What we actually got is a tiny band of free-thinkers, re-imagining what “programming” should be like, and what “programmers” should be like. That’s not a bad thing. As new languages go, Rakudo is among the most exciting. But, it’s in that thinly-stretched startup mode where you only get to pick one of “quick, cheap, or good” and it’s optimizing for “good”. In the long-run, that focus will be crucial to Rakudo’s success.

Back to the impact on Perl. Ultimately, the wonderful distraction of Perl 6 has proven… well.. distracting. What was once a very good thing for Perl, is paradoxically now bad for Perl. I recently explained this to a friend as a story of two brothers, Perl and Rakudo Wall:

Perl Wall has finished his advanced graduate degree, and is out building
his career. He was hugely successful for a while, but lately something
strange has been happening. When he goes on interviews, for some reason
people keep pulling up his younger brother’s resume by mistake, and then
tell him “Sorry kid, you don’t have the experience for this job”. But
really, he’s perfect for the job, if only they’d look at *his* resume,
instead of looking at his brother’s.

Rakudo Wall is still a teenager, and walks to the tune of a different
drummer. He’s smart, but he does things his own way. Sometimes
he takes a little longer than the other kids, and sometimes he
leap-frogs past them with a brilliant insight even the teachers don’t
understand. People keep telling him that he should be just like his
older brother. But he’s not, and he doesn’t *want* to be exactly like
his brother. He wants to be himself. Someday, he’ll be awesome, even
outshine his brother. But he’ll get there in his own time, and his own way.

Right now, Perl and Rakudo are getting in each other’s way. They’re like conjoined twins, trying to live separate lives, but always anchored to their brother. That doesn’t mean I love Rakudo any less than I love Perl. I love them both, and want them both to succeed. But their paths are very, very different, and they each need the freedom to walk their own path. The way to grant that freedom is stunningly simple: accept that it is what it is, and let each go its own way, with its own chosen identity. Let Perl be Perl and let Rakudo be Rakudo.

I sincerely hope to see Perl 7 released quite soon. No fuss, no bother, no long list of “blocking features”. Just BAM! ship the next version of Perl (5) as Perl 7. And I sincerely hope the greatest success for Rakudo. I don’t even care if it takes another 13 years to release, it’ll be worth the wait.

The King is dead. Long live the King!

UDS-R Architecture Preview






I can’t wait for tomorrow!