The slides of my presentation at OpenStack Summit in Paris 2014 (download ODP source, 9M).
And the sessions’ recording:
The slides of my presentation at OpenStack Summit in Paris 2014 (download ODP source, 9M).
And the sessions’ recording:
Seven straight full time working days, starting from 9am Saturday and Sunday for the second edition of OpenStack Upstream Training to the feedback session on Friday evening at 6pm are finally over and I’m starting to catch up.
I spoke on Monday, highlighting some of the findings of my research on how to change organizations so they can better contribute to OpenStack, later lead with Rob, Sean and Allison the creation of the Product working group (more on this later). The double-length session dedicated to addressing the growth pain in Neutron has removed the “if” and left the question to “how and when do we empower drivers and plugin developers to take their fate in their own hands”.
I think this has been one of the most productive summit, I’m leaving Paris with the feeling we keep on improving our governance models and processes to better serve our ecosystem. Despite the criticisms, this community keeps on changing and adapts to new opportunities and threats like nothing I’ve seen before. I’m all charged up and ready for the six months of intense work leading up to Vancouver!
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).
Self-Exposure: Hidden Influencers become OpenStack Product Managers | Rob Hirschfeld, Albert, and Debra are discussing. Toggle Comments
The pages on wiki.openstack.org have been growing at a fast pace and it’s time to give the wiki more shape: new contributors, end users and operators are having a hard time finding documentation since over time it spreads across many places. The wiki can have a role at directing readers where most appropriate. Luckily we have a team ready to help give the ~350 pages a more solid navigation and fixing content while at it:
We are keeping track of things to do on the etherpad: Action_Items_OpenStack_Wiki. Shari and I started implementing Katherine’s proposed taxonomy: it’s visible as a navigable tree on https://wiki.openstack.org/wiki/Category:Home.
- Block Storage
You can see this live on the wiki on https://wiki.openstack.org/wiki/Category:Programs. Fairly straightforward except that over the years some of the pages have started with describing a project and have now been repurposed to illustrate a Program. Look at Nova page for example: the name of the page is “Nova” but the title is OpenStack Compute. We’ll definitely have to shuffle content around. For example, the Category:Programs page can be considered a duplicate of the wiki https://wiki.openstack.org/wiki/Programs page: since everything on mediawiki is a page, the Category pages can be edited and can be redirected to/from like all other pages. In this case, it would make sense to make high level content like Programs more of a dynamic page, like Category:Programs. The cool thing of this approach is that we can probably create new category page for new programs automatically when modifications to the programs.yaml are approved via jenkins.
Adding a taxonomy and templates (more on this later) will help newcomers discover relevant content and find information more easily. While we implement the changes to the wiki we’ll also be reviewing the content on the pages, delete or mark as obsolete the old stuff and make things more readable for all. You can keep up with the progress by looking at RecentChanges.
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.
I think we’re starting to see too much friction and pain from contributors to OpenStack plugins, drivers, extensions: a lot is going on and joining the community feels like boarding a bullet train while it’s running at full speed. We’ve been doing a good job pulling people in the OpenStack community and educate them with our tools, processes especially for contributors to the Compute, Storage, Networking pieces of OpenStack; there are margins to improve life for “casual” contributors and newcomers in general.
The main problem I think is that we’ve been treating all developers like they all have the same amount of dedication to the collaboration effort. We’ve been asking every person contributing to OpenStack to act the same way, whether they were fixing a small bug in Keystone or refactoring Neutron’s code: same gerrit review workflow, same process for blueprints/specs. We assumed always that anybody at any given time had the same level of knowledge of deadlines and recent changes to the processes. We are requiring people with radically different objectives and set of incentives to know and do the same things. I think this is starting to become too much of a problem for the community. We are already having conversations about this (split drivers, Neutron incubator, refocus summit, modify the legal requirements) and will continue discussing in Paris.
The one thing that we should start improving immediately is the documentation for new contributors. New contributors have lots of resources available like the Welcome Guide, docs.openstack.org/developer, lots of wiki pages of varying degree of correctness and quality, tips and tricks on blog posts, upcoming video series, IRC support and Upstream Training. Based on what I hear from some, they struggle because these are in different places and owned by different people. A place where this content is shown in a more coherent way would be a great improvement.
There are two efforts to improve various pieces of documentation: the Documentation program wants to redesign the Docs portal, and a new portal is being designed for developers of applications based on OpenStack. The Documentation program is not responsible for developers’ content on the Docs portal, it simply hosts the materials produced directly by the programs. While we wait for a redesign of the Documentation portal, I think we can start by fixing the wiki pages. With the help of a taxonomy produced by volunteer Katherine Cranford and Foundation’s staff Shari Mahrdt, we’ll give a bit more structure to the OpenStack wiki. Stay tuned for more details.
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”.
If you try to solve a problem with the wrong tool you’re likely going to have a frustrating experience. OpenStack developers have been using the same workflow to plan and manage development of OpenStack software over time, they chose a set of tools appropriate for the project’s software development. Developers use blueprints define the roadmap for the various projects, the specifications attached to a blueprint are used to discuss the implementation details before code is submitted for review.
These are the tools for the developers and this doesn’t mean that blueprints and specifications are the only way to interact with developers. Operators and users in general don’t need to dive in the details of how OpenStack developers organize their work and definitely should never be asked to use tools designed for and by developers. When I read the place of a non-developer in the openstack community I immediately felt her pain: she was asked to use the wrong tool to solve a problem. I think this case is a major misunderstanding but the comments on the post signal that this is not an isolated case.‘s post
The most common way for a non-developer to highlight a flaw in OpenStack is to file a new bug report. Bugs can be defects that need to be fixed or they can be requests for enhancement. In this case, Dafna filed a bug report and interacting with the triager, they agreed that the reported bug was not a defect per se but more of a request for enhancement, a wishlist.
In order to fix a defect or implement a wishlist item, developers need to file a blueprint (and a specification) before they can start writing code. If the person who filed the original bug report is also a developer then s/he can go ahead and continue carrying on the process, file a blueprint to solve a bug # and write specifications (when needed) to describe the details of the implementation. Users interested in the bug can chime in adding comments to the bug and to the specs, provide input to developers.
The process above works in similar way when the person filing the bug is not a developer, like in Dafna’s case. The proper flow of bug #1323578 would have not required Dafna to file a blueprint and specs, but to have a developer do that. Users are required to interact closely with the developers to discuss the implementation details, and that’s where the new specifications process helps. Gerrit may not have the best UI but it’s definitely better than holding discussions on a mailing list. Adding comments and holding conversations with the developer assigned to resolve the issue, on the bug report itself is also a valid option.
While I think that as a community we have plenty of ways to improve how we include users and operators in our conversations, in this particular case, I think frustration came from being pulled in the wrong place from the beginning.
PS: To be super-clear, in this post I’m using the terms developer and operator to describe a role, not a person. One person can be at the same time a developer and an operator, and act at times as a developer writing blueprints, submitting code and as an operator filing bug, giving comments to specifications.
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.