I spent a week in April at the OpenStack Summit in Austin. This was my fifth OpenStack Summit, so it was not an entirely new experience. I attend the summit to organize the vBrownBag TechTalks, so I see the event quite differently from many of the attendees. One of the things I learned early on is that there are actually two summits going on at once. There is the conventional trade show, with vendors whose business is selling products and services to customers. But there is another summit, a little less obvious, that goes on alongside. The Design Summit is where some real magic takes place. One of the big differences between open-source and proprietary software is how public the software development process is.
The Design Summit is where the OpenStack projects do their planning for the coming release. This is why the summit is always just after a version release. The summit itself also bears the name of the next release, since that is what the summit designs. This summit in Austin was named Newton, which will be the name of the OpenStack release just before the next summit, in Barcelona.
With proprietary software, future features are a business advantage. It is important not to let competitors know what you are working on. A group of product managers meets in private and works out a roadmap for development. Then, a team of developers works in secret to build the next big thing. Users of the software usually have a few weeks’ notice of a new version release and what features the new version will contain. With open source, everything happens in public. For any large project, there will be multiple developers working largely under their own direction. The OpenStack Design Summit is where they agree what they will work towards. Developers and implementers of the projects spend time discussing what they need and want, which leads to a roadmap of development needs for the next release. This happens in an open space where anyone who registers can take part. Typical attendees are IT professionals who build and operate OpenStack environments at significant scale. Also at the Design Summit are developers from some of the vendors who are making sales in the vendor pavilion. I suspect that there is little interaction between the developers and sales teams that are both paid by these vendors. The Design Summit is heavily developer focused. This supports my expectation that OpenStack deployment is usually a developer-led project and generally requires developer skills.
The vBrownBag TechTalks are not part of the Design Summit, but they do attract a lot of developers. TechTalks are twelve-minute-long presentations that the vBrownBag crew records live at the show. Some of the presentations are the core of sessions that didn’t get accepted for the main conference schedule. Other presenters prefer the shorter format and submit only for vBrownBag at each summit. We do these TechTalks at various vendor conferences like VMworld and Cisco Live, as well as at the OpenStack Summit. At the vendor conferences, the TechTalks are largely about how to use the vendor’s software to solve business or technical problems. They have lots of great value for technical people working with the vendor’s products. One thing I noticed about OpenStack Summit is that the majority of TechTalk presenters are developers of one sort or another. Their TechTalks are often about how they saw a gap in OpenStack and developed a piece of software that fills the gap. This reinforces my view that deploying OpenStack is a developer-led process. It also suggests that enterprise customers may be failing at OpenStack. They use infrastructure and operations teams to deploy OpenStack.
There is also a cultural difference between open-source and normal enterprise software. It is a result of the openness. In open-source development, you have a public list of bugs and disclose every bug as soon as you are aware of it. In open source, this is how software is improved: bugs are openly disclosed, and developers often fix the bugs as a matter of personal pride. In commercial software, the list of faults with the software is strictly need-to-know information. The less our competitors know about our problems, the better for us. The result is far more visibility for the quality of open-source software. I’m not sure that many enterprises are happy to implement software that they know has 300 bugs. On the other hand, being kept ignorant of the quality of the software they deploy is perfectly acceptable. OpenStack Summit is an interesting place.