You’re probably thinking this is a clickbait title, and admittedly I did take some liberties with the current political adventures happening. The concept I’m putting forward here is that the OpenStack community is often being divided on some very important and challenging areas.

The reason I call this TrumpStack is that there is a strong representation of what we may refer to as establishment OpenStack advocates, who are firmly holding onto the hope that it will become an AWS competitor inside the on-premises data center and in the public cloud realm as well. This group is largely made up of developer-focused folks. A lot of the consumers from this crowd lean towards entirely API-focused use of OpenStack. They tend to work higher up the stack in the application tiers.

On the other side of the aisle is the citizen brigade who wants the private cloud capability, and also wants it to support some of the enterprise capabilities. These are the elusive “Enterprise” customers. They don’t see why there can’t be high availability features baked into the core of OpenStack projects. The Enterprise consumer doesn’t understand why we should be pushing back on packaging and making the deployments simpler even if it adds some extra layers. This group is largely made of of traditional virtualization administrators and architects. This audience has had a tendency to think bottom up when looking at infrastructure solutions.

Here are just a couple of examples that have popped up recently that help to show where there seems to be a dichotomy in the ecosystem.

Packages or Build From Source?

This discussion came up at the documentation design session which I attended in Austin. There was a genuinely visceral reaction when the topic came up around the OpenStack Install Guides hosted at http://docs.openstack.org/ which show the installation process for multiple Linux derivatives.

The seasoned developers in the room had a strong push towards wanting to create a guide which will use a build-from-source methodology to ensure that the results have a higher chance of being current and consistent. The response from the other faction in the room (myself included) was that moving away from packages towards building everything from source would create an even higher barrier to entry, and will alienate many newcomers to the platform.

We can see that there are very good reasons for the build-from-source. We can also see why using packages is much more convenient for installing and building. My opinion is that anything we do to create more friction and process around the installation and adoption of the platform reduces the chances of it growing.

Fully packaged OpenStack builds and leveraging projects like Fuel can be the way for us to accelerate the adoption as well, but the grass roots sysadmin adoption will be found by making those first few steps as seamless and frictionless as possible. The discussion on the documentation went quite well considering the tumult that was possible as many opinions were put forward. The end result at this juncture was to continue to support the current guides, but to also review better ways to organize them for consistency and better UX flow.

We Name our Cattle on This Farm

Tired of hearing about Pets vs. Cattle? Most of us are. The underlying concept is important. While OpenStack, and most private and public cloud platforms, is geared towards workloads that have resiliency build into the application, many of the folks in the industry just aren’t there yet. The question comes to OpenStack advocates now: Should we push away potential adopters of the platform because they may have workloads that aren’t entirely appropriate for a typical “cloud” infrastructure?

The only thing more contentious than the Pets vs. Cattle debate is trying to find who originated the phrase. For the record, I also try to steer folks away from this phrase, because in some highly populated parts of the world, cattle are much more highly regarded and protected than pets.

Feature Creep and the Big Tent Challenges

When you build an open platform which has the power to get into a feature creep situation. That is where too many voices are involved and take the project in multiple directions. Sometimes they are parallel development streams, but they are multiple points of focus that can cause contention between features.

If you search for projects within the incubation phase, you will find that many projects present the same hopeful goal. These parallel projects also present entirely different methods. How many different ways can you achieve a feature? Well, that depends on who is leading that feature development. What are the key requirements? Which is the base from which to define the “standard” of how to mark it feature-complete?

That’s the interesting thing about democratic solutions. If you look at the Whitehouse petitions site, there are a lot of rather odd petitions on there, but if they get enough signatures, they have to be evaluated by the Whitehouse administration.

Speaking of voting…

Voting Challenges: The Summit Selection Issue

This one came up with the most recent Call for Proposals for the OpenStack Summit in Barcelona from October 25th-28th. in the past, you were able to submit your proposal, and once the deadline arrived, you were able to share out your sessions for voting. Voting was open to anyone with an OpenStack ID. This meant that you had to be a part of the community in one way or another to be able to vote.

For this round, the voting was no longer done by login. It also didn’t provide the ability to give links to your specific sessions in the voting mechanism. To top that off, there was also an interesting discussion sparked by Randy Bias on Twitter about it.

The OpenStack Foundation is deliberately making it difficult to promote abstracts for the Summit over social media? #FAIL — Randy Bias (@randybias) July 27, 2016

The core of the conversation is around who should be choosing the content that appears at the Summit. We saw some opinions that it should be chosen by track chairs, and many feeling that the process should go on as it did in the past. There were some oddities around the tooling and UX from the previous voting systems.

One suggestion came in that I think could be positive: attendees of the Summit are the voting public. This would reduce the “ballot stuffing” as some call it where a company with significant size of staff could add many votes in favour of their own presenting staff members.

Why Do I Call this TrumpStack?

Baiting headline aside, lets think about what is happening. We have a system being developed which was born of the creators as an open source ecosystem. Everyone has a level playing field, and technical committee members are chosen by vote to make decisions to give technical direction to the sub-projects. The OpenStack model is good, until suddenly there is an onrush of people who want to use it, but they also want features that don’t necessarily fit with what the technical committee membership agrees should be under the hood of the OpenStack core.

We have a citizen uprising to the establishment (albeit an open source and quite a well-working ecosystem IMHO). Even the best open source projects can be steered when the growth becomes rapid. This recent tweet from Kelsey Hightower shows regarding

challenges in the container standardization gives another good example:

Review this thread and tell me why Docker deserves to be the stewards of an open container standard? @solomonstre pic.twitter.com/vt6XD9taKk — Kelsey Hightower (@kelseyhightower) July 29, 2016

I’m on both sides of the argument in parts here. Standardization is important to the overall ecosystem. I applauded Alex Polvi for his work to drive Rocket and the surrounding specs that support it. I also see that the team at Docker could find themselves at the whim of a slower moving standards body which could be seen as dampening innovation.

I wish that I had the solution. This isn’t exactly some kind of Kobayashi Maru or anything, so we have to ease back on the deep political arguments. I also recognize that the role of the PTL and Technical Committee for OpenStack do find themselves in a difficult spot.

Do we further the will the of the people which could steer the ship into some more choppy waters? Do we treat it as a benevolent dictatorship and take a more aggressive approach to reduce feature creep.

There are a lot of ways that we as a community can help with this. I continue to be thankful for the work of the PTLs, developers, supporting vendors, and everyone who contributes to the OpenStack ecosystem in any way. In my opinion, we all have a stake in this.

That’s the interesting thing about democracy in open source. We may not like the opinions on any side of the ecosystem, but we have to listen, and sometimes we have to make difficult choices. Looking forward to seeing the continued growth of this very exciting and open community.

Share this: Twitter

Facebook

LinkedIn

Reddit

Pinterest

Email

