Now that my PDX Trimet pass expired, it’s time to reflect on OSCON 2014. Unfortunately, I did not ride my unicorn home on a rainbow; this year’s event seemed to be about raising red flags.
My four key observations:
- No superstar. Past OSCONs had at least one buzzy community super star. 2013 was Docker and 2011 was OpenStack. This was not just my hallway track perception, I asked around about this specifically. There was no buzz winner in 2014.
- People were down on OpenStack (“DownStack”). Yes, we did have a dedicated “Open Cloud Day” event but there was something missing. OpenSack did not sponsor and there were no major parties or releases (compared to previous years) and little OpenStack buzz. Many people I talked to were worried about the direction of the community, fragmentation of the project and operational readiness. I would be more concerned about “DownStack” except that no open infrastructure was a superstar either (e.g.: Mesos, Kubernetes and CoreOS). Perhaps, OSCON is simply not a good venue open infrastructure projects compared to GlueCon or Velocity? Considering the rapid raise of container-friendly OpenStack alternatives; I think the answer may be that the battle lines for open infrastructure are being redrawn.
- Free vs. Open. Perhaps my perspective is more nuanced now (many in open source communities don’t distinguish between Free and Open source) but there’s a real tension between Free (do what you want) and Open (shared but governed) source. Now that open source is a commercial darling, there is a lot of grumbling in the Free community about corporate influence and heavy handedness. I suspect this will get louder as companies try to find ways to maintain control of their projects.
- Corporate upstreaming becomes Imperative. There’s an accelerating upstreaming trend for companies that write lots of code to support their primary business (Google is a primary example) to ensure that code becomes used outside their company. They open their code and start efforts to ensure its adoption. This requires a dedicated post to really explain.
There’s a clear theme here: Open source is going mainstream corporate.
We’ve been building amazing software in the open that create real value for companies. Much of that value has been created organically by well-intentioned individuals; unfortunately, that model will not scale with the arrival for corporate interests.
Open source is thriving not dying: these companies value the transparency, collaboration and innovation of open development. Instead, open source is transforming to fit within corporate investment and governance needs. It’s our job to help with that metamorphosis.
Rob Hirschfeld 
Open Source ‘going corporate’ is a great thing.
For one thing, I don’t think the community-of-individuals model is dead, or dying.
It’s just being overtaken in volume by corporate collaboration which works at scale that makes it easier for open source projects to projects pay ( or more commonly, make their cost and value transparent and measurable ).
Today’s open source landscape features a greater number and quality of individuals or small companies working as consultants around their chosen technology.
What corporate use has done is professionalise development through methodologies, processes and, conventions and standards,, introduced and created processes and conventions that filter down to the small business, consultant through their assistance and interaction with large businesses.
Many ‘corporate’ developers and engineers I know ( and I loosely include myself in that ) learnt everything they know about networking, operating systems, databases and a whole lot further up through open source. I could never have afforded to learn anything had I had to pay first at the age of 16/17.
let’s hope that these paradigms of development continue to feed and nourish each other.
LikeLike
Thanks for your comments! I agree with you – it’s great to have a salary for building open source products. I agree that corporations funding open source projects expect to professionalize the management of the projects. I’ve been hearing developers object to that type of control as “heavy-handed” or “too commercial.” I think that we need to recognize that open projects will need more governance (or projects with better governance will grow more). That’s a trade-off worth discussing.
LikeLike
Sure there are aspects of large-scale distributed development that, it could be argued, blunt creativity by taking away the sort of human interaction that happens on smaller more focussed projects.
I would imagine that large-scale projects become more akin to civil engineering challenges than to sculpting, where creative innovaton takes a back seat to the need to avoid mistakes.
LikeLike
+1. I don’t think that process has to blunt creativity but projects with lots of momentum don’t tolerate radical refactoring.
LikeLike
Pingback: The Upstream Imperative: paving the way for content creators is required for platform success | Rob Hirschfeld
I think this article touches on some very interesting points. First – regarding the growth of the community: It’s so incredibly positive to see the momentum that OpenStack has achieved and continues to acquire. The scope of collective development power available to it now is, essentially, staggering. There’s an extremely fine line between heavy-handed governance and anarchy. On the one hand governance can be and also be perceived as very negative. However expecting a community as large as OpenStack has become to put together a final result that is completely coherent, without any guidance or direction or (gasp!) governance is likely just wishful thinking. I don’t think it’s practical to assume that processes and models that got OpenStack to where it is are necessarily what’s needed to get it to where it needs to go next.
Second – regarding corporate involvement: Hopefully the open source model will “automatically” filter out behavior that is overtly self-serving to a particular vendor. (Meaning if a contribution basically only benefits one vendor then the community is hopefully likely to de-prioritize that.)
LikeLike
Jim, thanks for the insights. I very much agree that process growth/change should be expected. I hope that we can learn from other projects and avoid reinventing processes.
LikeLike
Pingback: 7 Open Source lessons from your English Composition class | Rob Hirschfeld
Pingback: Operators, they don’t want to swim Upstream | Rob Hirschfeld