Category Archives: Business

to whom it may concern

I’ve needed to write this for a long time.

I’ve struggled with how to frame everything and what tone would be best.

I would like to believe this could help OpenStack, but I have my doubts that anyone who can do anything will, or they already would have. I would like to think reading this might help someone else, but it might end up just being for me, and I’m ok with that.

For context, I was around when OpenStack was announced at OSCON in 2010 as the VP of Engineering at Cloudscaling. I have experience deploying and operating OpenStack and CloudStack implementations of some significance. I also evaluated Open Nebula, Eucalyptus and Nimbula along the way, as I really wanted a good solution to the cloud problem. I spent time consulting on OpenStack projects and last focused on OpenStack when I was hired by Jesse Andrews at Rackspace, before my whole team left to go to Nebula.

I’ve since moved on to focus on other things, but still watch OpenStack as I have a literal vested interest in the success of the project as well as many friends I care about in the community.

OpenStack was born into a vacuum created by the acceleration of AWS adoption and features, plus missteps by Eucalyptus and CloudStack with respect to the value of Open Source communities and how to cultivate them as a vendor. When OpenStack was first announced, I felt there was so much potential. I certainly made an effort to evangelize the project. Now, while many will declare victory, I’m afraid most of that potential will not be realized or worse, that OpenStack will leave a wake of bad projects that people unwittingly mistake for operable software solutions.

OpenStack has some success stories, but dead projects tell no tales. I have seen no less than 100 Million USD spent on bad OpenStack implementations that will return little or have net negative value.

Some of that has to be put on the ignorance and arrogance of some of the organizations spending that money, but OpenStack’s core competency, above all else, has been marketing and if not culpable, OpenStack has at least been complicit.

My compulsion to record this for posterity was triggered by details in the last release and related chatter around other announcements.

I would like to highlight the ‘graduation’ of Ceilometer. Ceilometer is a tragedy masquerading as a farce. In my opinion, this project should not exist and as it exists should not be relied upon for anything, much less billing customers.

First, the idea that monitoring/metering is something that should be bolted on the side of a cloud is almost as nonsensical as adding on reliability and scalability. Experience operating a web service that has been developed with instrumentation will quickly disavow anyone but a masochist of the bolted on approach. Second, Ceilometer’s implementation is such a mishmash of naive ideas and pipe dreams without regard for corner cases and failure scenarios, that Ceilometer’s association with OpenStack should be seen as a negative and graduation of the project calls into question the literal foundation of OpenStack decision making. Ceilometer’s quality is bad, even by OpenStack standards.

When I was still inclined to take actions about OpenStack related things, when Ceilometer was just a name someone proposed, I made all these same arguments but with more detail, specifics and depth. What I came to understand is that solving metering was not the primary motive. No one really cared about that. Certainly not in the way one would approach a project they intended to deploy and operate. The primary motivation was to have a project so that someone could be a Project Technical Lead (PTL).

That precedent started at the beginning with the creation of Glance, a project that never should have existed, and the subsequent creation of PTLs. The dynamics of the perceived prestige of a PTL superseded other considerations.

This dynamic allowed for a splintering of vision and mandate. If there has been any one thing that I have seen waste time implementing and operating OpenStack, that would have to be trying to coax the disparate OpenStack services, often from the same ‘release’, to work together. Press releases trumpet a new release of OpenStack as if this was working software and the naive ‘Enterprise buyer’ would rush headlong into that assumption hopped up on adrenaline and hubris. I accept Conway’s Law as a truism. Organizations will build software that reflects the communication of the organization. If the people implementing Keystone, don’t respect or understand the people implementing Nova, well, at least there is a PTL…

Don’t get me started on networking or storage…

I used to be hopeful, evangelistic even, about the possibility of a cloud service provider ecosystem built on open source. Now I am quite skeptical and feel that opportunity may be lost. Not that OpenStack doesn’t work, or at least that it can’t be made to, given certain competence and constraints, but that OpenStack doesn’t have the coherence or the will to do more than compromise itself for politics and vanity metrics.

People contribute to projects for a variety of reasons. OpenStack releases like to highlight the number of committers. That’s not a bad thing, but it’s not necessarily a good thing either. How many engineers do you think are working on AWS? GCE? How many of those committers will be the ones responsible for the performance and failure characteristics of their code? How many of those committers are dedicated to producing a world class service bent on dominating an industry? There has been some interesting, and even impressive work dedicated to improve code reviews and continuous integration, but that should not be confused with a unified vision and purpose. The per project difference in emphasis and the focus on nuances of stylistic python over other considerations of quality, let alone architecture and failure conditions determine OpenStack’s present and future. OpenStack wants to differentiate with features going up the stack, but has still not solved the foundational infrastructure and is busy furiously discussing what should be considered ‘core’. Projects that prove to be unreliable and a poor experience for operators and users ultimately damage the OpenStack ‘brand’.

OpenStack loves to declare its own victory. OpenStack’s biggest success has been getting vendors excited about abdicating their cloud strategy in lieu of going it alone. As long as OpenStack succeeds at that, there will be no shortage of funds for a foundation, summits and parties. Ultimately, if that is OpenStack’s primary accomplishment, Amazon (and perhaps others) will run away with the user driven adoption as service providers until there is nothing left of OpenStack but bespoke clouds and mailing list dramas.

I’m not sure anyone wants my advice at this point, but here it is.

  • Focus on users, not vendors. If there can’t be a benevolent dictator, there has to be an overriding conscience. The project setup solves vendor political problems more than user software problems.
  • PTLs end up being trophies. Electing PTLs every cycle is distracting and impacts continuity. Everything about this hurts OpenStack. Don’t confuse the way things are being done with the best way to do them.
  • Define a core and stick to it, or acknowledge that your governance is broken and make OpenStack an explicit free for all.
  • Stop declaring victory with vanity metrics. Divide OpenStack google trends number by the number of marketing dollars spent. The total number of committers is less meaningful if OpenStack is an excuse to sponsor parties around a collection of disparate projects.
  • Make ‘OpenStack’ brand mean something to users. Stewardship is greater than governance. If OpenStack is just a trough for the old guard IT vendors to feed slop to their existing enterprise buyers without regard to the technology or user experience then OpenStack has completely lost the plot. Make ‘OpenStack’ mean something and defend that.

I’ve certainly exceeded my 0.02 limit. Do what you will.

To all my friends at the OpenStack Summit, enjoy what Hong Kong has to offer… 幹杯.

incubators are a ghetto

Update: Following up to all the conversations, I’ve had about incubators and Silicon Valley since last week, I didn’t mean to imply ‘a list’ or that there are not other incubators besides YC, TechStars and 500 Startups that create value. Though, like most things, I think the tendency is a Pareto Distribution. I would also like to point out that there is nothing wrong with programs that are not explicitly designed to help companies get investment, just don’t mention investment as a central feature in marketing the program.

The way for anyone to establish that value is to provide transparent expectations and data about their program. Done.

There has been an explosion of incubators in the last few years. Most of them suck. Some suck so bad that the net value created by the program is probably negative. I’m not going to name names. This is just about results.

Let’s start with a story. There are minor variations, but I’ve seen it played out in real time more than once in the last few years. The story goes like this. An incubator has a class of companies, they give them a little cash, they have a weekly session with a mentor or whatever, time goes by, demo day, no one gets funding, fail, fail, FAIL.

what’s wrong

They tried to copy the Y Combinator model, and by ‘copy’ I mean cargo cult. They performed the outwardly obvious ceremony, but didn’t understand and thus couldn’t replicate the mechanics of cause and effect.

Y Combinator has had impact on the dynamics of startup formation and funding not because of the exact details of a program.  But the details are what cargo culters can see: three months, a dollar figure, weekly sessions, gogogo, demo day… the end , most of the companies dissipate.

To be successful an incubator has to do two things. First, create companies that are actually fundable, second, get them an audience with investors interested and able to fund. That’s it. That’s all. Connect the dots. Success.

create companies that are actually fundable

To accomplish the first, you can look at details like Paul Graham’s judgement of people and ideas, or Brad Feld’s numbers and analysis, or Dave McClure’s hustle and passion. You can look at the program, and the mentors. You can talk about lean startup pivots or vision or whatever. At the end of the day, there is a fairly narrow band in the total spectrum of business opportunities that are venture fundable (though that band still represents infinite opportunities). If through whatever process of filtering, coaching and pivoting, the resulting companies don’t represent an opportunity for plausible venture returns, then by definition those companies will not get funded.

The fundability is also a function of how the opportunity is represented. Raising a round of funding is telling the story of your company to a particular audience. If you can’t connect the right dots for the investors, they probably can’t connect them for you. I literally grimace when I meet founders who have come through these programs and don’t understand how to discuss the addressable market, the go-to market, let alone term sheets. The point is that a company is only as fundable as they are able to tell the story that they are fundable. And that skill is something that many incubators fail to teach. Which is a segue to what has to be in place to accomplish the second: get them an audience with investors interested and able to fund.

the network: the only thing that’s real

The traditional venture model ran on warm introductions. If you have an incubator that can’t make that hand off personally, or get the right audience in the room for demo day, then the value of the program is severely limited. So much, that I’d argue for what you trade in equity for the amount of money, the founders’ time would be better spent reading through Venture Hacks or ‘The Business of Venture Capital‘, and then hustling to social engineer introductions themselves.

As much as anything that’s what the successful incubators are leveraging. YC leverages the personal connections and reputation of Paul Graham et al. Dave McClure is PayPal Mafia. He knows people and more importantly, people know Dave. These programs, through the network of people involved, can make introductions to dozens of individuals who in many cases MUST fund startups. That is a competitive advantage.

out of the ghetto: advice for founders

What can be done?

If you are a founder looking at a program that hasn’t had at least 50% of the previous companies funded, you might reconsider the options. You may have a good experience and learn some things, but there is an opportunity cost. If your life’s mission is really to make something amazing happen with your idea and you have the resources to devote your time to that, then what are you waiting for. If the time spent and the equity traded isn’t going to open more doors for you than just working on the code and angel list, then that program might be a setback, because you’ll just have to do those things anyway and you won’t have the burden of sorting good advice from the bad. You will also inevitably be judged by the quality of companies you stand next to, at least in the context of the program.

If you can go to YC, Techstars or 500 startups, you should. I would. You’ll learn things and get a tiny bit of money, but the connections you make to the network of founders and mentors is what will make all the difference. That’s the fat head of the incubator distribution. I’m sure there are others that add value in the middle, but I want to encourage people to be aware of what you are getting into and for what. In addition to the time and equity commitment, be sure to get more data and weigh the options and benefits.

  • How many companies have been through the program and how many got funded?
  • Who are the mentors in the program and what are their backgrounds?
  • Can you get in contact with people who have been through the program? Especially founders that failed.
  • What are the other options? (for example, building something)

unsolicited advice for the well intentioned incubator

If you run an incubator and your earnest concern is the creation of value, this is my unsolicited advice. (Remember, there’s just two things you need to do, create fundable companies, get them in front of investors.)

  • If your companies aren’t getting funded, take it personally. Look at what your program creates and the relationships that are being built with investors.
  • If no one involved has ever been funded, that’s a problem. If nearly everyone involved hasn’t been funded or is in a position to fund, that’s a problem. Fix it. You have very little hope to create fundable companies otherwise.
  • The companies should be getting as many questions from you as they are answers, probably more… a lot more. Of course, that’s predicated on knowing the right questions to ask.
  • The incubator needs to be building relationships with investors as much or more than any of the companies. If no one running an incubator has or can build those relationships, how can they can help a company build relationships?

There will always be advantages in resources and relationships. That’s how the world works. Understanding that is the first step to gaining those advantages. Hope that helps.

tl;dr if an incubator is run by people who have never run a start up, never successfully pitched venture or haven’t got the cash on hand plus the risk tolerance to make considerable investments, the companies that accomplish anything will be in spite of the program rather than because of it. Some of these incubators appear to be nothing but a hobby for individuals of relatively high net worth, often having had nothing to do with venture investment in the past, to tell their war stories filtered through survivor bias to founders who have to build companies in an environment different from anything their mentors have ever experienced. The resulting bad advice and misguided effort may be a net negative for all involved, the founders and investors.

addendum: After writing this I found this, which could potentially be a useful for collecting and comparing data. There is a link there  to a post and literal dissertation on forming seed accelerator programs and a follow up to that. Jed Christiansen provides a thoughtful treatment of the subject with sound advice, but the primary focus is how to make an incubator appealing to the entrepreneur, while follow on funding is mentioned in passing as a complication. Venture funding is a pull system, there has to be explicit signals to pull and someone to do it. (if you don’t know what a pull system is, see me after class)

New Beginning: Cloudscaling

Cloud Rising

Every new beginning comes from some other beginning's end. --Seneca

Some of you already know this, but last week I joined the Cloudscaling team fulltime.

Cloudscaling helps organizations transition towards the application centric operations models that analysts/the blogosphere/random people can’t seem to define well (or quit arguing about) but refer to in generalizations as ‘cloud computing’.

We have a few interesting developments coming and a couple big projects we can’t quite speak freely about yet, but we provide strategic consulting and implementation assistance, especially for large organizations looking to invest in internal IaaS resources or to differentiate themselves as public IaaS providers.

So far, I’ve been getting up to speed on our projects and the tools, in addition to learning some things that I’ve typically been somewhat removed from, like layer 2 networks and other details most developers (and even many sysadmins) take for granted in their day to day.

The bottom line is Cloudscaling is working on pushing the boundaries of ‘Infrastructure is Code’. We can agnostically evaluate and implement solutions using the best tools and track the evolution of the space. We have a team with both breadth and depth up and down the technology, from the datacenter to virtualization, from hardware to APIs.

I’m really excited to be part of the team (although there’s some great people not on that page, like Lew Tucker ex-Sun Cloud CTO who just joined our board of advisors) and I’m expecting big things and a great year from us.

Look for some systems management and cloud related thoughts from me on the cloudscaling blog

Agile Infrastructure: The Movie

In a war between cowboys and ITIL, a small resistance fights for their ideals…

Dedicated to the notion that ‘the way things are done is not the best way to do them’, our heros struggle to liberate their comrades and add to their community of practice. Long live DevOps!

InfoQ just released just released this presentation, which Paul Nasrat and I gave at Agile 2009 in Chicago.

The presentation is quite long, but I hope people find something beneficial and would appreciate any feedback here or on InfoQ.

turn the page

Don’t cry because it’s over. Smile because it happened.
–Dr. Seuss

I’m no longer part of Reductive Labs. While this development is not quite heart breaking, I am always sad to leave behind something that I care about, but I also understand and feel strongly that this will be better for everyone.

Since raising venture funding, Reductive Labs has been building an adept team. That team has a critical mass in Portland, OR. There are now eight people there and I am tied to Salt Lake City for the near future, and who knows where for the next few years. Staying aligned with everything that Reductive Labs was doing and needed was becoming more and more of a challenge.

Puppet is a great tool and organizations get a lot of value from it. There are some exciting Puppet developments underway which present unique challenges and opportunities for both the technology and the business. I will now watch them from afar.

My involvement with Reductive Labs has been a period of pronounced growth. I learn many lessons about business and technology, that would have been difficult to learn any other way. I thank Reductive Labs and Luke Kanies for sharing the opportunity.

For the next month or so, I’ll spend more time with my family (when I’m not at the climbing gym and getting massages) and sort through a couple ideas.

Part of me wants to continue pushing the Infrastructure Renaissance forward in some capacity, and part of me wants to build something awesome, and part of me wants to work on stuff that matters.

Maybe there is a good way to combine them all together…

There are a lot of interesting problems in the world… (to solve or cause)

Insurmountable opportunity…

What are you going to do next?

The Four Steps to the Epiphany

I just read The Four Steps to the Epiphany by Steven Blank and I highly suggest the book to anyone with an interest in business.

The books is mistitled, but ‘The 47 potentially recursive steps to incrementally determine a business model and not waste a lot of money on bad assumptions‘ probably didn’t work.

Blank outlines a ‘Customer Development’ process in parallel with the development of the product.

There is an a clear bias for venture funded tech startups, and a more subtle enterprise bias, but the process and mindset being advocated is generally applicable, even when some of the anecdotes might not be.

The core message is that the ‘build it and they will come’ strategy sets the stage for epic failure, and the book is filled with examples.

In my opinion, the Customer Development strategy is really Test Driven Business Development. The steps are a series of experiments which test hypotheses about the potential product and the market. The end result is the product developed in tandem with the positioning and sales process in line with a strategy appropriate for the market.

The Four Steps outlines a taxonomy of Markets: Existing Markets, New Markets, and Resegmented Markets, for the purpose of matching the market type with an appropriate sales strategy. A reoccurring theme, supported with evidence, is that ramping up a sales team or building expensive infrastructure not aligned with the nature of the market can burn through a lot of cash.

The last section is about building companies. This is after you have a product and a market, and are looking to take things to the next level. The advice here is more philosophical, illuminated by scenarios where founders were unable to lead that transition and the examples where traditional professional management ruined promising startups.

The ideal leader is someone with the passion and vision of a founder who is also able to think strategically and delegate. (which is not to be confused with abdicate…)

If you are thinking about building a business, or in the process now, I recommend you take the time to read ‘The Four Steps’ as soon as possible.

%d bloggers like this: