I have recently started to regularly follow the mailing lists and the conversations are quite interesting.

It is quite evident that that OpenStack is starting to go through growing pains. It was quite evident as well from OpenStack Silicon Valley 2014 that was held yesterday.

OpenStack has grown from a minimal amount – where most of the developers knew each other personally, knew each others phone numbers, a good personal community – the way it should be. But as all good things, like all successful thing, it grows. This is what OpenStack looks like today.

Current OpenStack programs are listed below:

• OpenStack Compute (code-name Nova) - integrated project since Austin release
• OpenStack Networking (code-name Neutron) - integrated project since Folsom release
• OpenStack Object Storage (code-name Swift) - integrated project since Austin release
• OpenStack Block Storage (code-name Cinder) - integrated project since Folsom release
• OpenStack Identity (code-name Keystone) - integrated project since Essex release
• OpenStack Image Service (code-name Glance) - integrated project since Bexar release
• OpenStack Dashboard (code-name Horizon) - integrated project since Essex release
• OpenStack Telemetry (code-name Ceilometer) - integrated project since the Havana release
• OpenStack Orchestration (code-name Heat) - integrated project since the Havana release
• OpenStack Database (code-name Trove) - integrated project since the Icehouse release

New capabilities under development for Juno and beyond:

• Bare Metal (Ironic)
• Queue Service (Marconi)
• Data Processing (Sahara)

These are the core components. I do not think that I am exaggerating if I was to say that there are at least another 30 projects or Github repositories either on the OpenStack repo or the Stackforge repo, and a good portion of them are actively being developed.

Ideally each and every project should be independent from the other. This of course has its upside but also problems as well.

Let’s take an example.

Most of the core components use a central database, typically MySQL. Keystone, Neutron, Glance and so on. You could install a database server for each and every component – but that would probably be major overkill, so usually what will happen is you create different tables on the same database server for each component. This now becomes a shared dependency for all the components now using that Database server. The larger the number of components use it, the more things that need to be considered. It has to be made highly available, the MySQL queries of a single component should not have any major effect on any other component, and so on and so forth.

So you would think that if most components have decided on using the same database then we should do the same for all of the components? That would be a logical assumption. No need to over complicate things.

Along comes Ceilometer. I will not go into the reasons why, but it uses MongoDB, not MySQL. That just created a complication. I now need to know how to manage another database, back it up, replicate it, and make it highly available. In addition to MySQL.

I have seen this many times, my organization is as guilty as any other for doing things like this. A development group starts working on a product and look for what is the easiest way for them to deliver their solution. Sometimes a solution is chosen because it is a “hot technology” and other times, because the standard “just doesn’t cut it”.

(As a side note – a whole other discussion could be held here, is adhering to standards the right way – even if it is more difficult or takes longer, or get the job done in the best and fastest way possible – ideally it should be a balance of the two – IMHO)

Without clear direction from the product leadership, without a proper standard – things can go wrong very quickly.

That is how I came across a product (with about 30 components) that had 6 different database technologies:

• Cassandra
• Oracle
• CouchDB
• MySQL
• MongoDB
• Derby

That is

1. 6 different connection strings
2. 6 different database clients
3. 6 different backup procedures
4. 6 different High availability models

And so on and so on…

Is this a bad thing? Depends who you would ask. The people who developed it – they are happy – because they got the job done, product works and they did not create a dependency.

For those who have to deploy, manage, troubleshoot and support this product – THIS IS A NIGHTMARE! for obvious reasons, some of them mentioned above.

I think that the same is happening in OpenStack. The proliferation of projects, the number of developers and just the sheer size of the solution is becoming very hard to manage. Goals of one projects do not necessarily align with that of other projects, and cross project collaboration is not the “best” at the moment between the projects.

Randy Bias said yesterday in his talk at OpenStackSV (not an exact quote):

The problem  is that OpenStack does not currently have a unifying vision or product strategy. With the growth in programs, OpenStack’s more consistent mission starts to be degraded and less meaning around OpenStack occurs.

Each program team tends to have their own view of what OpenStack is. This does not mean there needs to be a dictator in OpenStack, but there does need to be product leadership.

(Source – vElemental)

Adrian Ionel also raised some thought yesterday on the subject.

The general developer does not care about things below or around the application like monitoring software, storage, network, or the hypervisor. They care about API quality and ease of use, feature velocity (not about OpenStack plumbing), and portability (devs want to write things once). Is OpenStack too intrinsic and poorly focused? Are infrastructure vendors moving focus away from critical areas?

In conclusion, he believes that there are some tangible things that can be done.
– Focus on API (awesome, well documented, easy to use, consistent, backwards compatible)
– Invest in ease of use vs flexbile plumbing (could have too many options)
– Don’t move up stack partner instead (LB, DBaaS, etc)
– Reshape upstream engineering to foster open competition inside OpenStack projects (engineering come up with solutions and compete while staying in framework and let market forces choose) vs central planning

(Source – vElemental)

I am not sure I agree with everything that Adrian said, especially not the part about competition. Yes this does produce better products in the end – due to the competition, but it also generates a lot of work (and lines of code) that will probably go down the drain in the end. I do not think that the OpenStack Community is currently in the position to allow themselves that luxury. Code reviews and code fixes are not being completed in the fastest time possible. Added to that extra code in two competing projects for the same purpose will only emphasize this point.

One last thing. The OpenStack WTE (Win the Enterprise) initiative is something that should have been kicked off 2 years ago.

No matter how good the product is – if people cannot use it or it does not provide the functionality that people need, it will not be adopted.

There are things, basic things that the Enterprise needs today, and have been asking for a number of years and can get them today in competing products.

I am not saying that OpenStack has to cater for every single kind of workload, for every application, for every single scenario - not at all. But the vision, the direction has to be there. Lay down the basic foundation of what OpenStack is going after, when you think it will happen, and more importantly what will not be supported or worked on in the upcoming future.

The feeling that I have (and I am not the only one) is that each project is doing what is best for them – and not necessarily what is best for OpenStack.

The Technical Committee’s charter:

The OpenStack Technical Committee provides technical leadership for OpenStack as a whole. Responsibilities include enforcing OpenStack ideals (such as Openness, Transparency, Commonality, Integration and Quality), deciding on issues that impact multiple programs, providing an ultimate appeals board for technical decisions and general oversight. It is a fully-elected Committee that represents the contributors to the project, and more details about membership and programs may be found in its charter.

I think at the upcoming Summit this is going to be a hot discussion topic. The important thing is that it should be an open discussion, and I think taking into consideration not only the development part of the community – but also the User and operators as well.

As always I would be happy to help out in any way I can.

There has been a lively thread on the openstack-dev mailing list these past few days, largely to do with GBP. I don't want to go into the intricacies of what exactly sparked the discussion but rather to discuss one of the by products that came out of it.

OpenStack is now 4, and on its ninth cycle of development. There has been a huge amount of innovation that has gone into the product and I think that the community is now coming to a stage where these growing pains are starting to show.

I think it is part of human nature to like the next shiny thing. We are always looking for the next best thing.

Let me give you a classic example. What was wrong with the iPhone 4? Of course there will be those that say the new iPhone 6 that will be released in the not too distant future, is better, faster, more powerful, looks nicer etc. etc.

But if you look at it from another perspective, is is just a nice and shiny new toy, that basically does the same as your old phone.

Did you really need to get a new one, probably not. Is it nice to have a new one, I would definitely say so.

But have those annoying things from your old phone ever been fixed? Does your battery last longer or shorter with you new phone? Are there annoying bugs that have been around forever and have never been fixed?

Here is another example. There has been a cosmetic, but annoying bug in the vSphere client since forever. I am sure you all have come a cross it. When provisioning a new VM the first window focus will always jump to the location field instead of staying in the first field which is the VM name. Annoying as hell! But since this bug has been around, VMware have developed the dvSwitch, SIOC, NIOC, VSAN, vCloud, VCHS and more and more. But that bug has never been fixed.

I see this again as a question of innovation (and the next bright and shiny thing) or fix up those annoying bugs. Of course innovation will always trump the mundane work of maintenance. I have done it myself, more than once, focused on new projects instead of taking care of the stuff that needs to be fixed.

I do think that it is very hard to keep a proper balance between the two. Again human nature.

This is no different if you are a developer. Do I stabilize my code, I prove my code so that it works in a more efficient manner or do I let it chug away, in the same old manner and add a new feature that improves the product as a whole. It is a serious dilemma.

OpenStack is currently at a stage where there are some fundamental issues with the current state of the software components. There are a number of issues that are preventing the full adoption in Enterprise market – and yet a large portion of the development process is dedicated to the new and shiny stuff, and not to the stability of the product. Quite a while ago I wrote a post about release cycles – and why we are chasing our tails – and with OpenStack which has a release cycle once every six months this is amplified ten times over.

I would like to share with you something that Thierry Carrez (Chair of the Technical Committee and Release Manager for OpenStack) wrote as part of this discussion.

Hi everyone, With the incredible growth of OpenStack, our development community is facing complex challenges. How we handle those might determine the ultimate success or failure of OpenStack.

With this cycle we hit new limits in our processes, tools and cultural setup. This resulted in new limiting factors on our overall velocity, which is frustrating for developers. This resulted in the burnout of key firefighting resources. This resulted in tension between people who try to get specific work done and people who try to keep a handle on the big picture.

It all boils down to an imbalance between strategic and tactical contributions. At the beginning of this project, we had a strong inner group of people dedicated to fixing all loose ends. Then a lot of companies got interested in OpenStack and there was a surge in tactical, short-term contributions. We put on a call for more resources to be dedicated to strategic contributions like critical bugfixing, vulnerability management, QA, infrastructure... and that call was answered by a lot of companies that are now key members of the OpenStack Foundation, and all was fine again. But OpenStack contributors kept on growing, and we grew the narrowly-focused population way faster than the cross-project population.

At the same time, we kept on adding new projects to incubation and to the integrated release, which is great... but the new developers you get on board with this are much more likely to be tactical than strategic contributors. This also contributed to the imbalance. The penalty for that imbalance is twofold: we don't have enough resources available to solve old, known OpenStack-wide issues; but we also don't have enough resources to identify and fix new issues.

We have several efforts under way, like calling for new strategic contributors, driving towards in-project functional testing, making solving rare issues a more attractive endeavor, or hiring resources directly at the Foundation level to help address those. But there is a topic we haven't raised yet: should we concentrate on fixing what is currently in the integrated release rather than adding new projects ?

We seem to be unable to address some key issues in the software we produce, and part of it is due to strategic contributors (and core reviewers) being overwhelmed just trying to stay afloat of what's happening. For such projects, is it time for a pause ? Is it time to define key cycle goals and defer everything else ?

On the integrated release side, "more projects" means stretching our limited strategic resources more. Is it time for the Technical Committee to more aggressively define what is "in" and what is "out" ? If we go through such a redefinition, shall we push currently-integrated projects that fail to match that definition out of the "integrated release" innercircle ?

The TC discussion on what the integrated release should or should not include has always been informally going on. Some people would like to strictly limit to end-user-facing projects. Some others suggest that "OpenStack" should just be about integrating/exposing/scaling smart functionality that lives in specialized external projects, rather than trying to outsmart those by writing our own implementation. Some others are advocates of carefully moving up the stack, and to resist from further addressing IaaS+ services until we "complete" the pure IaaS space in a satisfactory manner. Some others would like to build a roadmap based on AWS services. Some others would just add anything that fits the incubation/integration requirements.

On one side this is a long-term discussion, but on the other we also need to make quick decisions. With 4 incubated projects, and 2 new ones currently being proposed, there are a lot of people knocking at the door.

Thanks for reading this braindump this far. I hope this will trigger the open discussions we need to have, as an open source project, to reach the next level.

Cheers,-- Thierry Carrez (ttx)

So I go back to the question – the title of this post.

Innovate or Stabilize?

I do not have a clear and definitive answer to this dilemma. On the one hand if you do not innovate – then you will get left behind, your competition will beat you – because they have the next brightest and shiny thing – and you are the dinosaur.

But if you only innovate and do not fix things that are broken – your will not be seen as a trustworthy company – because you always let the broken things “stay broken”.

It is – like most things in life – a delicate balance that you need to find. You cannot only do one or the other. It will be a mixture of both, sometimes one will take precedence over the other and there will be time when that is reversed. In order to stay relevant – this mixture should be evaluated on a regular basis and focus changed when need be.

OpenStack specific - I personally think that the time has come to perhaps to go to a different mindset – one option that just comes to mind – is to dedicate one in four Openstack releases to only fixing stuff that is broken, no new features will be added – unless everything else that was supposed to be fixed, has been dealt with. It could be that one in four is too often – or maybe not often enough, but running at such a pace, is not good for the community, not good for the operators and in the end will not be good for those who will use OpenStack.

(Even Redhat – “the mother of all opensource” only releases a major version release once every 3-4 years)

Just by the way – I assumed that the OpenStack projects were run in a more Agile oriented mindset – evidently – they (as do we all) have a great deal still to learn.

I would be very interested in hearing your thoughts and suggestions on this subject, please feel free to leave them in the comments below.

1. How many years have you been working with OpenStack?
2. What is your favorite thing about OpenStack?
3. What is that you dislike about OpenStack?
4. If there was only one thing you could change/improve in OpenStack - what would it be?
5. Where do you think Openstack will be 3 years time?

Beth Cohen, Cloud Technology Strategist – Verizon

1. 3 years.
2. It is a strong community of companies and people who want to build the best cloud platform in the world.
3. It is a bunch of petty developers snipping at each other from their little fiefdoms.
4. Better integration of the parts.
5. Everywhere!

Sean Winn, Cloud Services Network Engineer – CloudScaling

1. 2 years.
2. I love that OpenStack is an open-source, community-developed system which, when leveraged properly within an organization, can have tremendous impact on every aspect of how that company does business. The effects of OpenStack on business operational efficiency and agility are incredible to me.
3. Lack of cohesiveness between projects is one of the biggest problems that I see facing OpenStack. Features are sometimes developed without consideration of other OpenStack projects implementations of same or similar features.
4. More cooperative efforts between projects to develop features with parity.
5. The most widely deployed data center and cloud solution.

Kenneth Hui, Business Development Manager, Cloud Solutions – EMC

1. 2 years.
2. The collaborative nature of the community.
3. Lack of focus in terms of development. Too many people chasing the newest shiny thing.
4. Better product management.
5. Leading private cloud platform.

Nick Chase, Technical Marketing Manager - Mirantis

1. 2 years.
2. The "open" nature of OpenStack means that anybody can get involved, and anybody can make it do what they need it to, if they are willing to put in the work. The possibilities are endless, and I'm passionate about that.
3. I'm sure there's much that I "dislike" exactly, though there are some things I wish worked better, or were easier to use. Deployment could be a little easier, of course.
4. Public perception. :)
5. Complete convergence so that hybrid and multi-cloud are not just normal but transparent.

Kevin Jackson, Principal Cloud Architect – Rackspace

1. 3 years.
2. The fact it's an open source, globally collaborated project that is the first choice when discussing cloud technologies that you can deploy yourself.
3. Release cycle of 6 months with very little support at present to easily upgrade to match this cadence.
4. Neutron/Networking - we need to quickly move on from the "Nova-network" vs "Networking" discussion ASAP.
5. We'll see "OpenStack Compatible" stickers on hardware and software showing ease of integration with the standard privately deploy cloud software.

Anthony Veiga, Senior Network Engineer - Comcast

1. 2 years.
2. The flexibility to plug the parts I want and omit the parts I don't. Plus, it's open source so I can't parts I need (which my team has done a lot of).
3. I dislike the primarily vendor-driven nature of its development. More users need to get involved, and the Foundation should recognize that coders aren't the only contributors.
4. Add community processes for locking out intentional roadblocking.
5. A multi-billion dollar per year industry.

Sean Collins, OpenStack Developer – Comcast

1. 2 years.
2. Being able to make design decisions that affect the entire company I work for.
3. Gerrit, Nitpickers.
4. Nitpickers.
5. Probably where it is currently.

Vinny Valdez, Principal OpenStack Enterprise Architect - Red Hat

1. 1 year.
2. I particularly enjoy how expansive, dynamic and flexible all of the projects yet they all come together in unison.
3. Many concepts sound great in theory but are not always proven or tested.
4. Move everything to MongoDB.
5. The de facto standard way to run applications.

Alexandra Settle, Technical Writer – Rackspace

1. 1 year.
2. The community involvement and dedication everyone has to the project.
3. Unfortunately the documentation is not up to the greatest standard it could potentially be. This however is an ongoing project and I hope to see it through.
4. Documentation.
5. Hopefully still progressing. Lots of community based projects die once a 'bigger and better' project is introduced.

We are down to the wire – last two days to vote for the sessions you would like see at the upcoming OpenStack Summit in Paris.

There are a large number of categories that you can choose from as you can see below:

You will need an account to cast your vote.

It is quite interesting to see that some of the sessions are targeted at how you can migrate your workloads away from VMware and onto OpenStack, something that I think people will be looking into a lot more in the near future.

I also have a few sessions that you can cast your vote – if you so choose..

OpenStack Design Guide Panel

In July, 2014 The OpenStack Foundation brought twelve members of the OpenStack community together at VMware HQ in Palo Alto, California to produce the OpenStack Design Guide in just 5 days.  This panel brings many of these authors together for an open discussion about how to architecture an OpenStack cloud.

Bring your real-world questions and be prepared to talk OpenStack architecture with a panel of experts from across multiple disciplines and companies. We'll be drawing on real architecture and design problems taken from real-world experiences working with, and developing solutions, built on OpenStack. Following a brief introduction, panelists are ready to field questions from both the moderator and audience members and provide ongoing discussion the design process for architecting cloud solutions based on OpenStack.

Cisco's Media Solutions journey to the cloud with OpenStack

This session will go over how the Video Service provider group has added focus to deployment of its platform to support OpenStack. How this has evolved over the past year, the challenges that came up along the way and how these challenges were addressed - and solved.

Moving from a VMware Centric Architect to an OpenStack Architect

I have been designing VMware clouds and architectures for the past 4 years, and have now moved my focus to OpenStack. The change was not a simple one. There are terminology differences, architectural differences, differences in use cases. Differences in considerations regarding storage design, networking, automation, deployment - across almost every single aspect of the solution.

In this session you will learn what kind of change in mindset is needed, how to adapt to different architectural constraints, requirements and technical decisions.

Automated Deployment of OpenStack on Cisco UCS and Nexus

The Cisco OpenStack Installer provides automated deployment of OpenStack core components, as well as monitoring, storage, and high availability components. The release schedule of Cisco OSI parallels the community release. Where possible, Cisco OSI provides unmodified OpenStack code. Every new release of Cisco OSI follows the latest community stable release; however, in some cases Cisco might provide more recent patches that have been accepted into the OpenStack stable branches, but have not yet become part of an OpenStack stable release.

The Cisco OSI code update policy is to contribute code upstream to the OpenStack project and absorb patches into Cisco OpenStack Installer after they have been accepted upstream. Cisco deviates from this policy only when patches are unlikely to be reviewed and accepted upstream in time for a release or for a customer deadline (in such cases Cisco applies the patches to the repositories, submits them upstream, and replaces the local change with the upstream version when it is becomes accepted). Cisco also uses and contributes to modules from other upstream sources including Puppet Labs on StackForge.

In this hands on lab you will learn how to deploy OpenStack with the the Cisco OSI - knowledge that you will be able to take back with you to your organization and utilize for your own deployments.

Bringing Operators, Users and Developers closer together

This session proposal came as a result of a conversation on a blog post with Stefano Maffulli with regards to the acceptance of non-developers into the OpenStack world.

What tools are needed to interact with the developers - and the "developly challenged" people who are now starting to interact with wider OpenStack community. Because of the plethora of tools and the substantial on-ramp and learning curve in order to adapt - non-devs are finding it hard to contribute-voice their concerns or help.

This session will go over the tools used today, which tools should be used and when - and what we can expect in the future

Remember – you are the one who decides what content you want to see – your vote counts!

Over 6 weeks ago I posted that I was going to embark on a journey, another book journey, and this time it was an OpenStack one.

Go ahead and read the post OpenStack Design Guide Book Sprint.

I have been wanting to write this for a while – but so much has been happening – that I just have not yet got around it until now.

I first would like you all to visit these two posts:

• Five Days + Twelve Writers + One Book Sprint = One Excellent Book on OpenStack Architecture – Nick Chase
• The OpenStack Architecture Design Guide Book Sprint – Kevin Jackson

As were the others, I was also skeptical about if such a process was even possible – but it was and I find it was actually a great success.

Everyone I have spoken to since the sprint was surprised that you actually can write a book in 5 days, it just shows that with a group of dedicated, task driven individuals – that have a deadline, and a common goal, it is possible.

So how did it actually work?

VMware (thanks to Scott Lowe) was kind enough to host us for these five days.

It was the first time I had actually been to the VMware campus – so this also was a first for me.

The diversity of the people involved was – I think – a good mix. There were Networking people, Openstack people, Architects, Storage Architects, Writers, Infrastructure Administrators, Project managers, a bit of everything. Each of us had input from a different aspect into the content that was going to go into the book and how it would be written.

The first day was mostly dedicated to the book structure, what the content should be about – who the audience should be, layout and such.

A good amount of brainstorming, discussions – getting to actually know each other – because not everyone was acquainted with everyone else.

The graph on the picture above is actually better explained here

Each of the vertical lines is a day. As you can see the concept of what actually goes into the book is mainly done on Day 1 and a bit on Day 2. On Day 1 you also start creating the content where most of it is done on Day 2-4 – where at the end of Day 4 – almost all of the content is actually done. Revision starts on Day 3 and continues all the way till the end. And this exactly how it went.

We broke up into groups that would do the writing according to chapters. At first discussions in each group – what should go into the chapter, then high-level chapter points and then after that churning out content.

We had some problems with the software that we used, mainly because the majority of us are used to having tools where you can collaborate simultaneously on the same document (Google Docs or Etherpad) and here we were limited to one person on a section at a time. We found the middle ground of working with all of the above and synchronizing content – that allowed us all to work efficiently and keep the flow of the Sprint going.

I expected there to be some bottlenecks along the way – due to the fact that in order to have the book come out as though it was written in a “single voice” – it needed to go through what Adam (our moderator) called a “filtering process”. That mean it needs to go through one or two people that will organize the content with the same narrative, line of thought and style. And evidently that is what happened towards the end

Obviously we had different writing styles – so adaptations needed to be made along the way.

semicolon ";" abuse here at #OpenStackDesign :)

— Maish Saidel-Keesing (@maishsk) July 10, 2014

After many complaints, we achieved team selfie! #OpenStackDesign Absent: @scott_lowe @hui_kenneth @itarchitectkev pic.twitter.com/wfpjMygSVP

— Alexandra Settle (@dewsday) July 11, 2014

@JamesSchallau Just world-shattering decisions like whether or not to use “you” in the #OpenStackDesign guide. :-)

— Scott S. Lowe (@scott_lowe) July 9, 2014

And so we trudged on – writing, editing, creating diagrams, and re-editing.

The combination of the constant supply of caffeinated soft drinks, M&M’s and other sugar saturated stuff, was about enough to get us through the sprint.

Getting to the end of Friday with checkmarks across the board was a very satisfying feeling.

I had a great time, a wonderful experience. Out of all of the participants I had only ever met Scott Lowe, all the others were either through interaction over Twitter or other means, but not in person.

It was a enlightening experience, very satisfying and something I would definitely do again if I have the opportunity.

I hope my co-authors can forgive me for the Kosher food they had to eat during the Sprint – I must say home-made cooking (especially my wife’s) is a lot better than what we all got. So whenever you guys are are in Israel for a trip – I will be happy to invite you all for a home cooked meal.

And now for the finished product.

The online version…

Paperback – from Lulu.com

You can browse through a full set of pictures taken at the event here.

All the authors have proposed a OpenStack Summit Session for the upcoming Paris Summit -
The OpenStack Design Guide Panel – please feel free to cast your vote!

This one has been sitting in the drafts for a while.

What pushed me to publish and finish this post was an article posted by Brian Gracely,
Will Paris be the last OpenStack Summit?

The Openstack Summit is actually two separate tracks – one for users, and a second for developers. It is just by “chance” (not really) that they are held at the same location – at the same time – because they are catered for two very different audiences.

This is very apparent – even in the logo for the summits.

It is even confusing sometimes in regards to what the name of the summit is? Will this be the Juno summit (if you ask an Operator/User – yes it will) or is it the Kilo summit (Developers with give you a thumbs up here).

How the event works?

5 days. the first 3 are the Main conference, and the last 4 is the Design Summit.

And of course from the mouth of babes..

The Design Summit sessions are collaborative working sessions where the community of OpenStack developers come together twice annually to discuss the requirements for the next software release and connect with other community members. It is not a classic track with speakers and presentations. (The Design Summit is not the right place to get started or learn the basics of OpenStack.)

Steve Ballmer – you remember him? He loved his developers….

The OpenStack Foundation treats the OpenStack Developers – differently. They are the people who create the product. Therefore they receive special treatment.

And by special treatment I mean:

• The Design Summit is called a Summit, the rest of it is called the Main Conference
  (see above)
• A completely different part of the conference only for developers – this includes:
  • Separate rooms
  • Separate schedule
  • Separate website for schedule
  • Separate submission process and voting for Design sessions
• Constant refreshments and treats (M&M’s and Snicker bars galore, drinks, fruit)
• Brainstorming area outside the discussion rooms
• Multiple power outlets in every single room and everywhere
• Every single ATC (Active Technical Contributor) receives a free pass to the summit.
  
  Individual Members who committed a change to a repository under any of the official OpenStack programs (as defined above) over the last two 6-month release cycles are automatically considered ATC.

Is this unfair – perhaps – but then again – these are the people who are creating the product – so it is in the Foundation’s best interest to keep them engaged, comfortable, happy and available to continue to contribute to the community and the products.

Back to Brian Gracely’s post. Because of the developers there will always be a OpenStack summit. Will it be the same as the past and upcoming summit – I do not know. But it is in the best interest of the Foundation to have the people developing the products, developing the projects to come together, talk, schmooze and also get the details hacked out of what will happen in the upcoming 6 months and the future directions of the product.

So in response to Brian – I still think that the Foundation will hold a summit – and it will always be its central event. The same way that all the major vendors have their own big Conference (Cisco Live, Redhat Summit, VMworld, etc.) every single year, but on the other hand they will make sure they have booths at all the other conferences as well (as a sponsor) it will be the same for OpenStack.

I think that the summit will continue to be here next year in 2015 and beyond.

Embedded below you can find the recording of my session
"OpenStack in the Enterprise - Are you Ready?"

You are welcome to go over the blog post I wrote about the event.

The full playlist of all the sessions can be viewed here

I have already submitted a few sessions for the upcoming summit in Paris.

Have a look at this infographic

Mazel Tov #OpenStack!

Not just for developers

Obstacles to adoption

OpenStack as a disrupting technology

Emergence of OpenStack ecosystem