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”.

How To Mix Agile And Software Developed By A Community

Back from Italian Agile Day where Stefano Fornari of Funambol with Marco Abis of Sourcesense animated a debate about mixing Free/Libre Open Source Software (FLOSS) and Agile development methods. I used to think that there was no issue because, after all, free software is a way to release software and it’s not a development method like many still think. Strictly speaking, what makes software free and open source is its license, not how it’s developed. But a lot of FLOSS is indeed developed in similar ways, with distributed teams, volunteer based contributions, merithocracy based leadership and so on. Some of these traits make FLOSS and Agile difficult to mix.

At Funambol we love Agile, me included, and we love to try new things so we proposed an experiment mixing Agile methods with community based development into a new Funambol Code Sniper program. The slideshow below summarizes the basis of this experiment based on the assumption that the community is the Product Owner of the new software.  The community will have to define the user stories and also to define when they’re DONE.

There are still a few grey areas, the biggest being how to distribute rewarding to contributors. I think they should be proportionate to the efforts put into the project. Even if it is possible to evaluate code contributions proportionally to story points (or hours/weeks), code is only a part of software development. Bug reporting, quality assurance, feedback and even writing user stories is important as well: how to evaluate these other kind of contributions? What do you think?