Open Stack

Yes. Strategic Product Management is the gap. We could try to initiate "Win
The Enterprise"-like efforts from the board in order to accomplish
strategic goals, but I don't think that is nimble enough, and possibly not
even appropriate.

We don't know how were going to achieve strategic product management
capability, what change that might entail and how we might gain acceptance
for that change, all of which I alluded to in an earlier email. I see these
as the critical issues to be addressed at a midcycle meetup. We can then
take the answers forward to the community for acceptance/ratification (or
the opposite)

Roland
On 24 Dec 2014 10:15, "Jesse Proudman" <jproudman at bluebox.net> wrote:

> Agree w/ this 100%.
>
>
> Jesse Proudman
> Founder and CTO
> Blue Box Group, Inc.
> w. www.bluebox.net
> c. 206-778-8777
>
> On Tue, Dec 23, 2014 at 3:05 PM, Randy Bias <randyb at cloudscaling.com>
> wrote:
>
> > Actually, Stefano, you didn’t even touch on the key motivation, from my
> > perspective, that sparked a lot of this.
> >
> > Here is the keynote I gave from September for those who haven’t watched
> it
> > yet:
> >
> >         https://www.youtube.com/watch?v=zOAb6wfBYxU <
> > https://www.youtube.com/watch?v=zOAb6wfBYxU>
> >
> > The point of the entire presentation is to highlight that for 4 years now
> > the PTLs and TC have believed that they own “tactical” matters.  In other
> > words, reviewing code, managing the integrated release cycle, and so on.
> > The entire PTL team in spring of 2014 at the first joint TC/Board
> meeting,
> > unanimously agreed that they have NO oversight of strategic product
> > direction.  Neither does the board.
> >
> > This leaves a gigantic gap since you can’t have “strategy” coming as the
> > effect of grass-roots developers committing whatever code they want
> > willy-nilly.
> >
> > IMHO, the remit of this group is to establish a process by which longer
> > term vision and product direction can emerge from within the community.
> > Product managers at the various constituencies of OpenStack are typically
> > on the hook for this within their businesses and I am hopeful that this
> > group can figure out a way (hopefully starting with my recommendations in
> > the presentation above) to work with the TC, Board, and the greater
> > community to come up with a process by which we are thinking about
> > OpenStack over greater than a 6 month time horizon.
> >
> >
> > Best,
> >
> >
> > --Randy
> >
> > 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
> >
> >
> >
> >
> >
> > > On Dec 23, 2014, at 2:52 PM, Stefano Maffulli <stefano at openstack.org>
> > wrote:
> > >
> > > On Tue, 2014-12-23 at 12:06 -0600, Kyle Mestery wrote:
> > >> My concern is I don't understand why this discussion would not happen
> > >> with the broader project, which is on the openstack-dev list, IRC
> > >> meetings, and in gerrit. Is there a reason any of those three things
> > >> won't work?
> > >
> > > Important question, worth a separate subject.
> > >
> > > The Development mailing list averages over 600 messages per week [1],
> > > from over 200 different people: managing that traffic is very hard,
> > > requires dedication and attention. I have identified three major sets
> of
> > > ATCs: core, regular and casual
> > > http://activity.openstack.org/dash/browser/
> > >
> > > Today we have:
> > >
> > > - Core (contribute up to 80% of integrated+incubated code): 254
> > > - Regular (contribute up to 90% of integrated+incubated code): 589
> > > - Casual (contribute the remaining 10%): 1,956
> > >
> > > I expect that core ATCs read and participate in openstack-dev, a part
> of
> > > regulars do too but the Casual contributors IMO are not
> > > reading/participating much. In my experience very few contributors have
> > > the skills *and* motivation to process such traffic effectively. Most
> > > contributors simply miss *a lot* of messages on the list because they
> > > can't (or don't know how to) manage high traffic email lists. The vast
> > > majority of Active Technical Contributors have no time/resources to
> > > process traffic on -dev.
> > >
> > > This means that managers of casual ATCs, which I expect this group is
> > > largely made of, have even less time/capabilities to follow -dev.
> > >
> > > A new group cannot really emerge and identify itself as a group inside
> > > another huge, trafficked channel. One reason for this mailing list is
> > > for this working group to establish itself.
> > >
> > > Besides the size of the -dev list, the topics discussed among devs are
> > > different than those discussed by the product/project managers in this
> > > WG: devs discuss engineering issues, like API stabilizations,
> > > versioning, interfaces etc. For this group the main topics are future
> > > roadmap, customer's impact and requests ...
> > >
> > > Operators have had a separate channel for a long time and have
> > > established themselves as a distinct group and learned how to engage
> > > with developers. The hope is that this group learns that too soon.
> > >
> > >> And if so, what is the purpose of the discussions here? Is it more of
> > >> just communicating changes? Call me honestly confused.
> > >
> > > Neutron's splitting of services and plugins is the sort of change that
> > > will affect equally core, regular and occasional contributors: core
> ATCs
> > > probably know all about it, a part of regulars also know enough but
> > > occasional and a part of regular don't know what that means for their
> > > bottom line.
> > >
> > > What will happen to products based on Neutron? How will that affect
> > > their sales/marketing? What are the governance/legal implications for
> > > the new repositories? What does that mean for defcore and openstack
> > > trademarks? I don't think that these questions can be raised and
> debated
> > > successfully anywhere else.
> > >
> > > /stef
> > >
> > >
> > > [1]
> > >
> >
> http://activity.openstack.org/dash/browser/repository.html?repository=http%3A__lists.openstack.org_pipermail_openstack-dev&ds=mls
> > >
> > >
> > > _______________________________________________
> > > Product-wg mailing list
> > > Product-wg at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
> >
> > _______________________________________________
> > Product-wg mailing list
> > Product-wg at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
> >
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
>