[Product] Why this group exists in parallel to other groups (was Re: Thoughts On Product-wg Deliverables)
Randy Bias
randyb at cloudscaling.com
Thu Dec 25 02:43:10 UTC 2014
I thought this was an interesting email, so I’m responding… See inline below.
> On Dec 24, 2014, at 9:19 AM, Richmond, Michael S <michael.s.richmond at intel.com> wrote:
>
> Les Vadasz, a near-founder of Intel used to say "find a tactic and build a
> strategy around it". In other words, even without a strategy written down,
> you have a strategy expressed through action.
The strategy in this case is explicitly stated as “find a tactic and build a revised strategy around it.” There isn’t a lack of strategy in that statement actually.
And I agree with the sentiment, although reality is a bit different in that what usually happens is that there is an unstated strategy that forms action more often than there is an emergent strategy through action.
Someone was relaying an anecdote to me recently about a CEO who would start meetings with something like this: “bring your solutions/ideas/strategies to the table now, because if you don’t, we’re using mine.”
Whether you get a strategy through a bunch of developers operating on an unspoken strategy or whether you formulate one in advance, the net of it is that people work towards a purpose, whether as individuals or a group. The purpose has a strategy, spoken or unspoken, and it manifests as a set of tactics that fulfill that strategy.
In other words, I agree with Les sentiment, but not the letter of his words. It’s more complex than that.
> This project doesn't lack for action, and each one represents somebody's
> (probably some company's) strategy.
>
> The problem is too many strategies. Finding a way to say no is probably
> the best thing that this community could figure out how to do. It is
> absolutely striking to me how much capability is being pursued in
> OpenStack outside the vision as portrayed in early videos on the project.
I think that’s an exceptionally insightful statement. This is exactly the problem. But it doesn’t invalidate my point which was that *OpenStack* lacks a product strategy. Of course, the various constituencies and community members have strategies based on their interests, but that doesn’t mean there is a unifying product strategy.
OpenStack is at pretty significant risk of collapsing under it’s own weight. As it is now, we’re on a suicide mission. We’ve got dozens of inbound projects that all want to move into integrated status and the current development cadence calls for a 6-month “integrated release cycle” even though it’s questionable whether all components really need to be tested together every 6 months or even integrated for that matter. Once we cross into 20+ projects this simply won’t be doable any more. Either we’ll break down to an annual release cycle (a mistake) or we’ll fix what is a fundamentally flawed approach.
And that goes to your last point there. OpenStack’s vision in the early days was fairly focused on infrastructure, although it’s mission was stated around “cloud”, which is in the eye of the beholder. As an inclusive, meritocracy, we have drifted and given rise to a rapidly growing set of interrelated but NOT interdependent (with exceptions) projects which we are currently and unfortunately committed to delivering a single monolithic release of at a fixed interval.
> The companies who are the early adopters and the most fervent adopters are
> most likely the ones pushing for new features. They are your best friends,
> yet your worst enemies.
>
> My advice: pick a use case and nail it, 100%, no bugs, easy to use. If
> it's only 10% of the world for whom that¹s enough, then sigh and say "next
> time".
>
> That's product management IMO.
Yes, product management is about saying no. But what’s perhaps more important here is recognizing that this is not a unified set of projects and can’t ever be. It’s too much. OpenStack should be a broader umbrella more like the Apache Software Foundation, with competing projects of various types, and the ability to put the projects together but no requirement to do so.
In other words, lots of two-pizza teams, so to speak, rather than pretending that this is one gigantic community with a single purpose (ship one piece of software every 6 months).
Then, each project could be run a lot more tightly with the ability to say no, focus on a use case and nail it. Right now, we say we welcome all ideas and we don’t say no, but force all code for a particular project into a single code base, even if it’s a force fit.
This will NOT work over the long term and I would say that the time is coming up very quickly where if it’s not fixed it’s going to be a major black eye and risk the project generally.
Sorry to get on my stump speech here, but I’ve been waving the flag on this by myself for a while and I’m realizing I need more folks out there who feel similarly to help give the feedback to the Board and to the Technical Committee. We MUST fix this in 2015.
—Randy
Ps. Please have your teams vote for me as an individual director this election if you believe I can make a difference:
http://www.openstack.org/community/members/profile/1089 <http://www.openstack.org/community/members/profile/1089>
VP, Technology, EMC Corporation
Formerly Founder & CEO, Cloudscaling (now a part of EMC)
+1 (415) 787-2253 [google]
TWITTER: twitter.com/randybias
LINKEDIN: linkedin.com/in/randybias
ASSISTANT: ren.ly at emc.com
More information about the Product-wg
mailing list