[openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

Zane Bitter zbitter at redhat.com
Thu May 10 20:38:37 UTC 2018


On 17/04/18 05:24, Thierry Carrez wrote:
> Hi everyone,
> 
> As you know the Technical Committee (the governance body representing
> contributors producing OpenStack software) meets with other OpenStack
> governance bodies (Board of Directors and User Committee) on the Sunday
> before every Summit, and Vancouver will be no exception.
> 
> At the TC retrospective Forum session in Sydney we decided we should
> more broadly ask our constituency for topics they would like us to cover
> in that discussion.
> 
> Once the current election cycle is over and the new TC chair is picked,
> we'll come up with a proposed agenda and submit it to the Chairman of
> the Board for consideration.
> 
> So... Is there any specific topic you think we should cover in that
> meeting ?

There's one topic I've been thinking about that I think would be 
valuable to discuss with the Board and the UC. I don't know if we still 
have time to add stuff to the agenda for Vancouver, but if not then 
consider this my advance submission for Denver.

OpenStack was bootstrapped using a very powerful positive feedback loop: 
in (very) broad-brush terms it started with a minimum viable product; 
users for whom that was enough to entice them tried it out and offered 
suggestions; vendors who wanted to sell to those users (as well as the 
users themselves) implemented the suggestions; both groups joined the 
Foundation, which marketed OpenStack to folks with similar needs.

Obviously that is a good thing, but it also comes with the danger of 
getting trapped in a local maximum. Users for whom the product has not 
yet met the threshold of minimum viability are generally not going to 
show up, and their needs are no match for the feedback loop set up with 
the users who _have_ shown up. (Specifically, we are arguably only just 
now approaching the minimum viability point for the types of cloud-aware 
applications that are routinely written against the APIs of the big 3 
proprietary clouds.)

How can we avoid (or get out of) the local maximum trap and ensure that 
OpenStack will meet the needs of all the users we want to serve, not 
just those whose needs are similar to those of the users we already have?

Discuss.

thanks,
Zane.



More information about the OpenStack-dev mailing list