OpenStack is as start-up friendly as anything

I read someone complaining about OpenStack being not friendly enough to startups one time too many. Latest post by Rob Hirschfeld 10 ways to make OpenStack more Start-up Friendly made me want to respond. I just can’t stand the Greek chorus of complaints, especially from someone who sits on the board and can actually push for changes where necessary. I promised I’d spend time on his 10 points and here is my take on each of them:

Accept companies will have some closed tech – Many investors believe that companies need proprietary IP. An “open all things” company will have more trouble with investors.

Why is this an OpenStack problem? If the VC industry have a problem with open source then the problem is of open source as a whole or of the VC (depending on your point of view). Maybe customers prefer to buy open source based solutions instead of buying proprietary code from small startups. This is not an OpenStack issue.

Stop scoring commits as community currency – Small companies don’t show up in the OpenStack committer economy because they are 1) small and 2) working on their product upstream ahead of OpenStack upstream code.

Code is the most valuable currency in an open source project, there is absolutely no way OpenStack should be any different. Companies small and big will be contributing compared to their size and code is how a small company doing great work can gain more influence than a large company doing little stuff. If you’re saying that the community shouldn’t put first and foremost the “top ten” charts of companies contributing (like stackalytics does), then I agree with you. The Foundation celebrates individual contributors to the release and only counts company. This is not an OpenStack problem. Maybe it is a stackalytics problem and one of the reasons I prefer to partner with Bitergia for the community dashboard.

Have start-up travel assistance – OpenStack demands a lot of travel and start-ups don’t have the funds to chase the world-wide summits and mid-cycles.

OpenStack has already has addressed this problem with the Travel Support Program. In Vancouver the Foundation spent around $50k to send about 30 people from all over the world, from startups and students. If that’s not enough, I’m sure more money can be raised for that. This is not an issue, there is a solution in place already.

Embrace open projects outside of OpenStack governance – Not all companies want or need that type of governance for their start-up code base.  That does not make them less valuable, it just makes them not ready yet.

I don’t even know where this comes from: is anybody forcing anyone to host code on git.openstack.org/openstack namespace? And isn’t the OpenStack project offering for free its resources to host code in our systems, without imposing governance or rules with git.openstack.org/stackforge? If there are companies interested in getting under the OpenStack governance, it’s their choice and based on my knowledge they choose because they get business value off of it. This is a non-issue.

Stop anointing ecosystem projects as OpenStack projects – Projects that are allowed into OpenStack get to grab to a megaphone even if they have minimal feature sets.

Even if this was a problem, and I don’t think it is, it should work in favor of startups: many of them have nothing to show but good intentions, for which a megaphone is exactly what they want and use. This is a non-issue.

Be language neutral – Python is not the only language and start-ups need to make practical choices based on their objectives, staff and architecture.

Nobody forces anyone to become an OpenStack official project (which requires some level of standardization). It’s a choice. And, in any case, there is a lot of javascript and ruby in OpenStack, with pieces in Go also coming. This is a non-issue.

Have a stable base – start-ups don’t have time to troubleshoot both their own product and OpenStack.  Without core stability, it’s risky to add OpenStack as a product requirement.

This is a tautology also it’s something that is being constantly advocated and keeps on improving.

Focus on interoperability – Start-ups don’t have time evangelize OpenStack.  They need OpenStack to have large base of public and private installs because that creates an addressable market.

So let me get this straight: IBM, EMC, Cisco are scooping up the first waves of startup that tried to build a product on the rudimentary OpenStack. Such big guns have the clout to create that large addressable market, lending their credibility to OpenStack as a whole. They also pay good checks to the OpenStack Foundation to power its awesome marketing machine.  This is good for startups: they ride on a wave created with someone else’s money.

Limit big companies from making big pre-announcements – Start-ups primary advantage is being a first/fast mover.  When OpenStack members make announcements of intention (generally without substance) it damages the market for start-ups.  Normally corporate announcements are just noise but they are given credibility when they appear to come from the community.

Yeah, right, like you can really put on a rule against vaporware. It’s the way this market has worked and will continue to work this way. Startups, in any field have to learn how to live with it. This is not an OpenStack issue.

Reduce the contribution tax and patch backlog – Start-ups must seek the path of least friction.  If needed OpenStack code changes require a lot of work and time then they are unlikely to look for less expensive alternatives.

Here I guess you’re talking about contributions to existing OpenStack projects, like Nova, Neutron and the like. If you think that some company can innovate fast on Nova while keeping the interoperability and stable release you talk about above then you’ve managed to confuse me. How realistically can you have some startup rip Nova apart and replace parts of it (all of it?) with the greatest big thing and keep the thousands of users out there with a happy upgradeable path, interoperability and stability? This is just impossible to reconcile. Startups cannot innovate on something that is mature and in production. It would be like asking Apache HTTPD to be something else. Guess what: nginx happened outside of Apache and it’s only natural. As a parallel to OpenStack, if someone comes up with a better Neutron, written in Go or Rust, and wide support I’m ready to bet it will be admitted in the big tent rapidly.

Let me tell you why I think that OpenStack is at least as friendly as any other business environment, and maybe more:

  1. Corporate sponsorship for startups is low, a lot lower than for big corporations. And there are ways to lower the admission price even further (just ask).
  2. The ecosystem is now so huge that cool startups innovating on the edges can get exposed to potential customers, investors and buyers very quickly (the megaphone works).
  3. The ‘cloud’ space is so rapidly changing that the big guys cannot keep up and count on startups to do the risky experimentation. There are lots of big companies in OpenStack, I suppose there are opportunities to find good contacts.
  4. The OpenStack Summits have a whole track dedicated to startups, with talks about funding, business, strategies, acquisitions and more.

And finally a reminder: all startups operate in extremely unfriendly environments, most startups fail for various reasons.

The recent exits of companies that innovated on the edges when OpenStack was held together with shoestring and spit as glue are to me a confirmation that the edges where innovation can happen are just moving outside of Nova and Neutron. It’s just normal and to be expected with the maturity of the project.

Let’s celebrate and be happy for Piston and Blue Box and the others. Startups will always be welcome and will always find a good home in and around OpenStack.

A week with Dell XPS13 9343 (2015 model)

Last week I have received the new Dell XPS 13 from the Sputnik program, the one with Ubuntu pre-installed. I wanted to vote with my wallet since I believe Ubuntu is a pretty solid desktop environment, on par with Mac OS X and various Windows.

Design-wise  Dell has produced a very good looking machine, nothing to say about that. Kudos to Dell’s team on designing something much prettier than a Macbook Air. The screen with no border is fantastic with almost no frame and it’s great to look at it.

The only complaint I have towards Dell are the options they picked for the Sputnix program: the only way not to get a touchscreen is to buy a severely limited machine with only 128MB disk. No way. All the other options force you to spend money and sacrifice battery power on a useless feature.

I think touchscreens are uncomfortable to use on desktops and I said so a long time ago. Unless the desktop OS is radically re-designed for touch and hand gestures on the monitor, it makes no sense. I would have never bought the touchscreen if Dell had offered a 256MB option with the regular monitor.

On the Ubuntu side there are quite a few glitches like this issue with the cursor becoming sticky on some applications even if the touch-to-click on the touchpad is disabled and some difficulty to adapt to the ultradense display. By the way, that’s another reason not to get the touchscreen: lower resolution is good enough on such a small laptop anyway. Installing Ubuntu Vivid also was a bit more painful than I thought.

All in all, I didn’t return the laptop as I thought I would, mainly because I needed to upgrade to a machine with 8GB rapidly.

Next steps for ‘Hidden Influencers’

With Paris only weeks away it’s time to announce that we have a time and place to meet people whose job is to decide what OpenStack means for their company. The OpenStack Foundation has offered a room to meet in Paris on Monday, November 3rd, in the afternoon: please add the meeting to your schedule.

There have been discussions in the past weeks about the hidden influencers, there was a recent call by Randy Bias to identify people, functions, groups, anything who can own the product OpenStack. The time is ripe to get to know who directly control the engineers’ priorities and complete the circle of end users, operators, product owners, developers.

Rob, Sean, Allison and I have the idea of creating a working group modelled after the Operators group: get people in the same room, some time mid-cycle and sync up on the development effort. It’s just an idea, mid-cycle is when the development roadmap gets more realistic, it’s more clear which blueprints are in good shape and which are less likely to make it into the release. We believe it would be valuable to have a moment when product decision makers can coordinate and get a chance to share their priorities.

The room is available for 4 hours, but of course we can use for less time if needed. It makes sense to start hacking some of the topics in the next weeks, before Paris. Please join the mailing list and introduce yourself while the agenda will be drafted on the etherpad. For naming the group you can join the async brainstorming session (drop names at random and don’t judge yourself nor others: everything is fair game).

 

How is your OpenStack team organized?

I’ve been collecting a lot of good insights talking to directors and managers about how their companies are organized to contribute to OpenStack. For geographic reasons I have mostly gathered comments from people between San Francisco and Silicon Valley and I’d like to expand the research.

I’m especially interested in learning about internal processes, system of incentives, things that impact performance evaluation for engineers contributing to OpenStack.

To expand the research I’m asking the OpenStack community to fill in this brief survey or contact me directly (stefano openstack.org) for a quick interview.

How do companies do OpenStack?

I’m cruising Silicon Valley these days asking “how does your company do OpenStack?”  to collect best practices and notable mistakes from various leaders of OpenStack corporate community. I’m hoping to build a ‘how to’ manual to help managers build better dev teams, more effective at collaborating while shipping products to their customers. This is an effort that goes hand-in-hand with training new developers with Upstream Training and other initiatives aimed at sustaining OpenStack growth.

I often have to explain to managers of OpenStack corporate members how and why to contribute to the project. The level of complexity reached has now exceeded the simple answers, like ‘fix simple bugs’ or ‘read the wiki pages’. For example, the participants to the Upstream Training in Atlanta had difficulties finding low-hanging-fruit bugs to work on: by the time they were ready to commit, someone else had already fixed it. Too much is going on at the same time, newcomers are confused at many different levels.

While we will keep training developers through Upstream Training (and other initiatives), we’re going to start talking to managers too.  I’d like to know how development teams are organized, how they balance shipping products to customers with contributing upstream, what incentives are in place that help or prevent contributions to go upstream, how career paths are influenced by contributions to the open source collaboration, etc.

If you’re managing a team of developers or devops, you’re a CTO, a HR executive or are managing in any way a team of engineers contributing code to OpenStack, I would like to talk to you: email me and vote for my talk proposal “How to maximize effectiveness of your developers contributing to OpenStack”.

Engage in technical discussions keeping in mind the OpenStack promise

When OpenStack launched, it made four clear promises to its community: Open Source, Open Design, Open Development and Open Community. Open Source for OpenStack founders has been clearly explained:

We are committed to creating truly open source software that is usable and scalable. Truly open source software is not feature or performance limited and is not crippled. There will be no “Enterprise Edition”.

I find it worth restating that promise because I believe the four ‘Open’ promises that largely contributed in boosting OpenStack growth. There is a conversation about what is Cinder itself and what’s the role of its drivers. It’s a highly technical debate and a very important one, where I think this promise needs to be reminded: There will be no “Enterprise Edition”.

I won’t enter into technical details because it’s not my role.  John Griffith and Ken Hui have a lot of interesting things to say about this and I suggest you to read their posts.  My personal opinion based on what I heard in Atlanta and read afterwards is that one approach puts Cinder in danger of becoming only useful if you pay a license to someone offering “value added” (better, freedom removed) pieces of hardware and software. That would be very shortsighted and that’s not what OpenStack is.  I think any leader of OpenStack has to be very careful when implementing changes that may put OpenStack’s promises in danger. The promises we made as a community are the first things to keep in mind during any conversation, technical ones included.

The quest to sustainable development of free software

A few articles on the topic of how to sustain development of free/libre software caught my attention lately:

It’s a hard problem, especially when you compare the revenues of a Red Hat selling “free as in freedom” software with the insane amount of money that can be made developing software that enslaves and sells users to advertisers. On the other hand, I know of a good amount of people making a living (and saving for the rainy days) while respecting users freedoms.