Tag Archives: facebook

Since content is king, platform companies (like Google, Microsoft, Twitter, Facebook and Amazon) win by attracting developers to build on their services. Open source tooling and frameworks are the critical interfaces for these adopters; consequently, they must invest in building communities around those platforms even if it means open sourcing previously internal only tools.

Huh? What is an “upstream imperative?” It sounds like what salmon do during spawning then read the post-script!

Historically, companies with a lot of internal development tools had no inventive to open those projects. In fact, the “collaboration tax” of open source discouraged companies from sharing code for essential operations. Historically, open source was considered less featured and slower than commercial or internal projects; however, this perception has been totally shattered. So companies are faced with a balance between the overhead of supporting external needs (aka collaboration) and the innovation those users bring into the effort.

Until recently, this balance usually tipped towards opening a project but under-investing in the community to keep the collaboration costs low. The change I saw at OSCON is that companies understand that making open projects successful bring communities closer to their products and services.

That’s a huge boon to the overall technology community.

Being able to leverage and extend tools that have been proven by these internal teams strengthens and accelerates everyone. These communities act as free laboratories that breed new platforms and build deep relationships with critical influencers. The upstream savvy companies see returns from both innovation around their tools and more content that’s well matched to their platforms.

Oh, and companies that fail to upstream will find it increasingly hard to attract critical mind share. Thinking the alternatives gives us a Windows into how open source impacts past incumbents.

That leads to a future post about how XaaS dog fooding and “pure-play” aaS projects like OpenStack and CloudFoundry.

In my opinion, one of the biggest challenges facing companies like Dell, my employer, is how to help package and deliver this thing called cloud into the market. I recently had the opportunity to watch and listen to customers try to digest the concept of PaaS.

While not surprising, the technology professionals in the room split into across four major cultural camps: enterprise vs. start-up and dev vs. ops. Because I have a passing infatuation with pastel cloud shaped quadrant graphs, I was able to analyze the camps for some interesting insights.

The camps are:

Imperialists: These enterprise type developers are responsible for adapting their existing business to meet the market. They prefer process oriented tools like Microsoft .Net and Java that have proven scale and supportability.

MacGyvers: These startup type developers are under the gun to create marketable solutions before their cash runs out. They prefer tools that adapt quick, minimize development time and community extensions.

Crown Jewels: These enterprise type IT workers have to keep the email and critical systems humming. When they screw up everyone notices. They prefer systems where they can maintain control, visibility, or (better) both.

Legos: These start-up type operations jugglers are required to be nimble and responsive with shoestring budgets. They prefer systems that they can change and adapt quickly. They welcome automation as long as they can maintain control, visibility, or (better) both.

This graph is deceiving because it underplays the psychological break caused by willingness to take risks. This break creates a cloud culture chasm.

On one side, the reliable Imperialists want will mount a Royal Navy flotilla to protect the Crown Jewels in a massive show of strength. They are concerned about the security and reliability of cloud technologies.

On the other side, the MacGyvers are working against a ticking time bomb to build a stealth helicopter from Legos they recovered from Happy Meals™. They are concerned about getting out of their current jam to compile another day.

Normally Imperialists simply ignore the MacGyvers or run down the slow ones like yesterday’s flotsam. The cloud is changing that dynamic because it’s proving to be a dramatic force multiplier in several ways:

Lower cost of entry – the latest cloud options (e.g. GAE) do not charge anything unless you generate traffic. The only barrier to entry is an idea and time.

Rapid scale – companies can fund growth incrementally based on success while also being able to grow dramatically with minimal advanced planning.

Faster pace of innovation – new platforms, architectures and community development has accelerated development. Shared infrastructure means less work on back office and more time on revenue focused innovation.

Easier access to customers – social media and piggy backing on huge SaaS companies like Facebook, Google or SalesForce bring customers to new companies’ front doors. This means less work on marketing and sales and more time on revenue focused innovation.

The bottom line is that the cloud is allowing the MacGyvers to be faster, stronger, and more innovative than ever before. And we can expect them to be spending even less time polishing the brass in the back office because current SaaS companies are working hard to help make them faster and more innovative.

For example, Facebook is highly incented for 3rd party applications to be innovative and popular not only because they get a part of the take, but because it increases the market strength of their own SaaS application.

So the opportunity for Imperialists is to find a way for employee and empower the MacGyvers. This is not just a matter of buying a box of Legos: the strategy requires toleratingenabling embracing a culture of revenue focused innovation that eliminates process drag. My vision does not suggest a full replacement because the Imperialists are process specialists. The goal is to incubate and encapsulate cloud technologies and cultures.

So our challenge is more than picking up cloud technologies, it’s understanding the cloud communities and cultures that we are enabling.