The story behind the open cloud ninja sloth

A couple years ago Sara was leading a project to figure out a way to convey the spirit of an open cloud to our internal audiences. A recurrent element in our journey has been the need to communicate visually not only the growing portfolio but also the multi-faceted open source strategy in the cloud, recognizing the many nuances and complexities of it.

Over the years we’ve crafted many vehicles to do so, from the simple ones like this spheniscidae, the hexagon, or the many logo slides to the complex like the portfolio, choice or approach ones. But we were missing simpler elements, particularly ones with a story that you can tell at a bus stop. I kept telling Sara to think as an open cloud enthusiast picking which temporary tattoo to apply. So working with the internal community the team came up with the open cloud ninja sloth:

As you can notice, the sloth came with the addition of an icon highlighting the “open” nature of the cloud, and our designer was quick to notice the hidden heart as well. Since then, the sloth and the open cloud icon have been spotted from stickers to challenge coins, but I was never expecting to find an Aussie wearing an open cloud ninja sloth t-shirt in Las Vegas (arguably, Vegas would be the one place where you could expect that)

Funnily enough, I didn’t know where he got his t-shirt from (Ignite Australia), and he didn’t know where the sloth came from. So I shared with him the story of the open cloud ninja sloth. The cloud with a heart that is literally open and the ninja sloth committed to that open cloud which might surprise you… even if slooooow.

I learned a ton from the journey of the open cloud ninja sloth and can’t stop encouraging teams to work on their icon and spirit animals even if they don’t have a product or a brand to push and even if they excel at any other type of visual expression.

At the very least it invites a question at a bus stop, or an impromptu storytelling session in Vegas.

With a hat tip to Ken, Ale and David, thanking Caroline for always reminding me when someone asks for the story and wishing Sara all the best in her new role!

Behind the whys

This post is inspired in equal parts by Ashley’s fantastic post on why she joined Microsoft and Keith’s one on why he left Microsoft. Both tell great stories about open source at Microsoft. Here’s my take on them.

There’s no shortage of stories when it comes to open source in this place. Later this summer, it’ll be 7 years since I joined Microsoft, every single day of which I’ve spent working passionately in the open source space.

I joined Microsoft as an expat living in Ecuador when the local GM asked me to lead open source strategy for a handful of emerging markets in the region. At that time, I had spent 8 years of my career focusing on open source, from community to product. Canaima had been in market for a year and I was actively applying the learnings from years involved in policymaking efforts in Venezuela where I had the opportunity to join congressional workshops and debate with Microsoft reps that would then become my colleagues.

Suffice to say that what was front and center in every conversation I had wasn’t associated with Microsoft back then, and that my decision to join Microsoft didn’t come without repercussions.

I was immediately dismissed from the board of a local free software group and countless networks and contacts closed, a few still to date. My dad gifted me a copy of this book shortly after a local newspaper ran an interview with me about open source which he disagreed with (he insists I’m reading too much into the gift) And like many others, I was also thrown into the world of Office and Windows, products I hadn’t used since I was a teenager.

There are increasingly more posts (like Ashley’s) that brilliantly explain why would someone come in those conditions, and I won’t bother you with mine because hindsight is 20/20, but let me say that as terrible as all of that might sound, it was also a true calling – a calling for transformation. And after all this time responding to that call, I realize how thankful I am for being able to say my entire career at Microsoft has been focused on open source.

On one of my first trips to Redmond, I got to meet a handful of others in my role around the globe, and we were starting to cross-pollinate that community with the high-profile hires Microsoft had then. Just a few years later I had an opportunity to come to Redmond and help lead that community – a community that is still heavily influenced by Ramji’s and Hilf’s contributions to the space.

While in LATAM I had an opportunity to drive impact in disruptive ways: from supporting a Postgres conference (5 years before we had this) to coaching Microsoft Student Partners in rolling out a Linux distro. In my first few years in Redmond, I worked on projects from deprecating taxonomy and helping write priority memos so it was unequivocally clear how we wanted to work with open source, to curating and sharing global best practices and defining field strategy, all things I did with Mark Hill while I was his CTO.

Of course, those were testing years. I would equate some of my experiences to trying to change a belt in a running engine. It didn’t take long to realize we needed a new engine, and I had the opportunity to write a spec for it in an internal forum called ThinkWeek. When the paper got a Certificate of Excellence (long story short, way too many Skypers voted for it) I realized that the pieces had arrived and we were being offered a chance to build it. John said it best in his ChefConf keynote: it was a mix of opportunity, changing demographics and strategy shifts.

And although open source is visible across the company, it’s much harder to hide it in Azure, a product that I had first interacted with in 2008 (when Miguel de Icaza ran an open source panel at PDC08) and that I had mostly ignored in my first years at Microsoft (arguably because it was called Windows Azure then) but that in my eyes provided a clear vehicle for that open source transformation I joined for.

And so that’s how I ended up in the cloud whirlwind a few years ago, focusing on the open source portfolio across Linux, Java, Node.js, DevOps and containers, helping define and land our approach to open source and supporting our work with the ecosystem at large, lurking behind papers and decks in partnership with amazing people like John, Julia, Joseph, Gebi, Mark or folks around the globe like Caroline, Frederic, Alex, Rafael, Olga or Tito.

The first time I traveled to Redmond I met a dozen of open source enthusiasts from around the world (it might have been Gianugo’s first day, too) and fast forward to today where I get to share with 700 of my colleagues in a Yammer group dedicated to open source in the cloud. My colleague Stuart volunteers to help employees that want to take the LFCS certification: that’s another 700. Our team lives and breathes open source in a way that lets us share market intelligence with customers, partners and the community at large.

Later this month at our yearly readiness conference we will have a dedicated open source track. At the Inspire conference, we’ll award the Open Source Partner of the Year award for the third year in a row. And there’s no shortage of industry chatter on this transformation – for which we’re thankful and we learn every day.

But it’d be very easy to get lost in what’s new and what’s different and not realize why it’s meaningful. Stories like Ashley’s give us not only a fresh perspective but the energy to run the engines. And stories like Keith’s and others who have pursued a different career at Microsoft or elsewhere after being part of this open source journey (like Alessandro, Sara, Ahmet or Nik) motivate us to do it right.

When college interns and high schoolers alike reach out to shadow and spend time learning about open source in a place like this, that’s meaningful. When a customer in France interrupt your presentation to ask for your take on a particular corner of the open source world so they can make investment decisions, well, that’s simply awesome.

And that’s why stories like these inspire all of us doing open source at Microsoft. Welcome, good luck, keep being awesome, stay in touch, whatever that is: here’s to more open source stories!

Perspective at //build

Recently I had the opportunity to share stage with some brilliant internal and external colleagues advancing open source in the cloud at //build, Microsoft’s developer conference in San Francisco. Beyond having been able to talk to about 400 attendees about how we’re approaching open source in the cloud, how customers are building open source applications in Azure and much more, speaking at //build had a very special meaning for me.

Before joining Microsoft, I didn’t have a lot of exposure to the Microsoft developer ecosystem, the Microsoft subsidiaries themselves or the employees working there. I was focused in a number of open source projects such as Canaima (Venezuela’s national distro) a number of communities and expanding a small open source system integrator in the region.

Most of my interaction with Microsoft was limited to public debates, at industry events or in Congress, or to the ISO/IEC 29500 discussion back in the days (both of which I’ve covered in this blog, in Spanish) However, around 2009 or so, the company I was a CTO for and Microsoft decided to create an Open Source Interoperability Lab in Venezuela. The idea was to document common hybrid technology use cases (such as Samba-based DCs in Windows environments, or PHP and ASP.NET communicating via ESB) and transfer that knowledge to customers.

As a result of that effort, I ended up being invited to and participating in PDC09 in Los Angeles. PDC was the precursor of //build, a yearly conference aimed at Microsoft-centric developers. There are 3 things I remember clearly from PDC09: one, was the “convertible tablet PC” they offered attendees (running Windows 7 bits that rapidly became Debian bits), the second one was the PHP SDK for Azure, and the preview access to that new “cloud” thingy, and the third one was an open source roundtable led by Miguel de Icaza that mainly talked about governance and CodePlex.

While I didn’t know it back then, a lot of the things discussed in that roundtable influenced my decision, about a year later, to join Microsoft and work in open source strategy; a journey that brought me to Azure in less than 5 years. But I digress, and that whole story deserves another post.

Maybe some of the attendees then foresaw that Microsoft would end up acquiring Xamarin, or that attention would be put in non-CodePlex initiatives, like GitHub. What I really didn’t expect was that all of that new reality would converge into a PDC-like event, less than 10 years after. This year at //build it did, and then some.

For me, speaking at //build was a humbling opportunity to reconcile the many worlds increasingly pulled together by the force of open source. From the announcements to the content and all other metasignals at the conference, it was incredibly exciting to see this transformation manifesting itself within Microsoft’s developer community.

It highlights the importance of leaving no one behind when we explore new paradigms and technologies in the cloud, and how every individual in the open source community can exert change in this industry.

Thoughts on growth and open source services

For many years I was infatuated with the idea of creating value out of open source professional services. To a certain extent, this is a function of when, where and how I was exposed to open source. Even today, after acknowledging the challenges of this model (the hard way) I find myself spending time modelling what needs to change in order to innovate it.

While today there are statistically no skeptics of the tremendous impact that open source software has had in and beyond the IT industry, thinking prevails that the open source opportunity doesn’t lay on professional services.

It’s commonly accepted that only a handful of players have found success in this model. In fact, some would argue that it can only be one that exhausts it for everybody else. Media commentators shun on rising startups whose business model smells too much of support and services.

As Ben Werdmüller recently wrote (motivating me to write this article) those services are not recurring and not scalable. And there’s also proof in the market that well designed, talented and recognized organizations eventually fail in their efforts to seize the open source consulting business.

Back in 2008, after 5 years selling open source services either as a freelancer or in small firms, I was invited to lead technical strategy for an open source focused system integrator in Venezuela. The organization had recently scored a support agreement with a large multinational hardware vendor for a subset of their customers’ Linux needs, and they were looking for a portfolio and an attractive environment for talent and for growth.

I spent the next 3 years building a team of 50+ in several countries in Latin America, shipping open source products and solutions and managing large consulting projects for customers in the public and private sector. That support agreement became 3 partnership agreements with large IT multinationals. Yet with all the impact, the challenges of dealing with the subtleties and complexities of the open source professional services challenge remained unaddressed.

There were numerous learnings I grabbed from that experience, ranging from managing a team of talented professionals who went on to highly successful roles in Europe and the Americas, to the art of marketing something as bland and commoditized as open source consulting.

Among the fun learnings: with a highly mobile talent pool in multiple countries we managed our daily operations via IRC. We also built a lean-and-mean sales process led by the delivery teams, not sales, embraced document and knowledge management and invested in the communities and ecosystem that help open source be successful.

But I digress. Portfolio-wise, we had organized our offering in three core areas (infrastructure, applications and databases) and a number of incubation areas that gave us a unique competitive advantage such as knowledge management and end-user experience (we focused a lot on Linux in the desktop) or business intelligence and unified communications. All with open source, all with Linux.

Yet market disruptions, such as government policy in an economy where public sector concentrates an overwhelming amount of spending power, contributed to mask the unaddressed. Since 2004, there was a stated pro-open source policy in the public sector which evolved into a number of unstated policies trickling to public and private sector alike.

When this policy was introduced there was a small talent pool to cover the complex needs of a public sector that sprawled beyond the vertical with plenty of Oil & Gas, Financial Services, Manufacturing and other needs. Furthermore, virtually no relevant foreign organization took advantage of this opportunity due to general market conditions, a difference between how similar policies were rolled out in, for example, Ecuador (where the US dollar is the local currency)

Therefore, supply and demand reality made margin management, a critical discipline in the services business, an afterthought. Plus, the depth and quality of our technical results was a catalyst for business opportunities so marketing wasn’t really in the picture. We were a go-to open source consulting company and we got away with selling bland OpenLDAP clusters and Asterisk IPBX as if they were actual products, repeatable and scalable.

And in exploring other models we found support was something we actually enjoyed: we were really proactive and fanatical about it and generally speaking never had to sell a support agreement. In the training side of things we managed to set consistency standards across courses and deployments but all accrued to that non-recurring base of services, to that dreaded hourly rate. So they were never differentiated sources of growth as it always converged in a consulting project.

At some stage we did invest in a products team that explored all the right things which years later hit the market (agile embedded with general purpose Linux OS, SaaS and cloud-powered IPBXs, analytics and insights, etc.) but the reality is that our operation corpora was built on a professional services foundation which made it unrealistic to detach. We tried using a different brand for our product labs, but the talent we had attracted and developed thrived in services.

I still see the boundaries of a VAR, an ISV and an SI as pretty artificial in the open source world, just as I find it less relevant to look at the boundaries of development and IT professionals with an open source hat on. Of course the business models are different, some are based in volume and depend on marketing and channel while others are based in margin and depend on trust and references. This mix is not different from what we’re seeing today in open source startup IPOs.

Today I don’t struggle to articulate a value proposition or find demand for the open source capabilities I’m selling. I’m struggling to find the right partner to help me scale. And I refuse to believe I can only go to a global SI or a well-known Bay Area ISV for those needs, when I have lots of VARs, SIs and ultimately great people in local markets who can land meaningful solutions. Yet I’m wary about putting all the eggs in the basket of building value out of open source professional services.

We’re now living interesting times where the successful players in this space are crowd sourcing services growth via channel. This is a fascinating move from an open source support and services behemoth and has a lot of potential if it can connect the local talent with consistency that accrues to growth.

In the meantime, common sense will still indicate that entering the market to sell non-repeatable open source professional services can be highly rewarding in developing people, acquiring and developing know-how and making an impact. It can even help reduce the consumption gap for a complex product and help build market share. It just doesn’t seem to be a high-growth strategy for most people out there.