Tag Archives: process

OpenStack doesn’t need a leader, it just needs to evolve

Third, and perhaps the best argument against OpenStack needing a leader, is the open nature of the beast itself. It’s precisely because there’s no dominant leader that OpenStack remains so transparent and competitive – everyone’s contributions can be seen by everyone else, and this drives people to do even better.

Most likely, those who say that OpenStack needs a leader do so because of history – previous open-source projects like Java, Linux and Android have all had a ‘dictator’ at the helm, but that doesn’t necessarily mean it’s the best path for OpenStack.

via OpenStack doesn’t need a leader, it just needs to evolve | SiliconANGLE.

If you remember correctly, Linux’s leadership and development model was largely dismissed by pundits, until it had 15 years of success under it’s belt. Then it became gospel of how Open Source projects should run.

But everything evolves over time. It doesn’t really surprise me that the pundits see OpenStack’s leadership model as different, and immediately dismiss it. We’ve got 3.5 years under our belt. Maybe at 5 or 6 everyone will now say all Open Source projects need to run like OpenStack.

Which would of course be wrong. While there are certain common threads between different Open Source communities, every community is different. Why? Because Communities are made of real people. Real people with different passions, strengths, weaknesses, biases, loves, constraints, and moments of brilliance. This isn’t something you can model with spheroid approximations of upstream developers. Replicating another project’s leadership model might be easy, but in most cases isn’t what your community actually needs.

Are there areas for improvement? Sure. There always are. But improvement is a watch word for OpenStack, something we apply everywhere: to code, to process, to communication.

So I agree, we don’t need a single leader. And the evolution that continues in OpenStack will be a key strength, not a weakness as the project goes forward.

Broken as Designed

I loved when I found this on Wikipedia on the Waterfall Process for Software Development:

The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[1] though Royce did not use the term “waterfall” in this article. Royce presented this model as an example of a flawed, non-working model (Royce 1970). This, in fact, is how the term is generally used in writing about software development—to describe a critical view of a commonly used software practice.[2]

Yes, the canonical reference to waterfall, the thing that coined that phrase, was “don’t do this, it doesn’t work”. And yet, for 30 years this dominated the software development industry.

A fire fighter’s job is not to fight fires

I was fortunate enough to attend a local IBM Academy event yesterday, which included a number of great talks.  Right out of the gate there was a talk by one of the people leading the Smarter Planet initiative, which was quite inspiring.  There are certain problems that can only be solved by an organization as big as IBM, and the fact that we, as a corporation, are diving into many of these: energy conservation, electronic health care records, water management, was something that made me proud to be working here.

Something stuck with me very much when the speaker was discussing the Fire Department of New York City.  The bulk of their job (time, energy, expertise) has nothing to do with putting out fires.  Putting out fires is the exception case.  The bulk of their time is spent preventing the fires from ever happening in the first place.  This includes creating sensible fire codes, inspecting buildings, education, and I’m sure dozens of other measures to make sure the fire never got started.

The image we have in our mind of firefighters is what they have to do when the preventative measures fail.  The next time you find yourself putting out a lot of fires, at home, work, wherever, it’s worth taking a lesson from the professional fire fighters, and working on shifting your time and energy to preventing the situation from ever happening in the first place.