Open Stack

Right, it's one of those areas where our choice of the terms ("users",
"core") ends up biting us because it's very overloaded.

We "fight for the users", we do "user surveys" and we have a "user
committee", but we generally fail to acknowledge our two layers of
"users": operators (deployers of OpenStack) and end users (people
actually using the REST APIs). And from the upstream perspective, we
actually have three layers: distributions/packagers of OpenStack are
also a "user".

I think we did a great job recently of reaching out to operators and
deployers, but not that great of a job reaching out to end users. Maybe
it's time to give end users a clear name and place. Continuing calling
everything downstream a "user" will likely continue to result in us
ignoring a large part of them.


Mark Collier wrote:
> I think we are in agreement.
> 
> Would love to work together on all the ways we can make end user
> feedback more central over time in everything we do as a community,
> including the end user working group, the evolution of the user survey
> to incorporate end user specific feedback, defcore, and helping the
> foundation hire a kick ass community manager singularly focused on this
> priority.
> 
> These are just a few examples.
> 
> 
> 
> On September 3, 2014 12:03:55 PM Monty Taylor <mordred at inaugust.com> wrote:
> 
>> I'd like to point out that Jim Blair and Infra are MASSIVE end-users,
>> and have no direct involvement in writing or deploying OpenStack. It's
>> easy to forget that and think that end users are not represented in
>> our current make up. We continually provide direct feedback on
>> elements of the experience which are poor, both to Rackspace and HP
>> who are our providers, as well as to the developers.
>>
>> The end user is pretty darned important, and when you attempt to be
>> one, it's crystal clear the OpenStack sees it's user base as the
>> deployers and distros. I would love to see us cowtow less to them and
>> pay more attention to the users.
>>
>> On Sep 3, 2014 11:29 AM, Mark Collier <mark at openstack.org> wrote:
>> >
>> > Great point Alan.  
>> >
>> > I think from an end user / developer perspective (using the term
>> here to mean those building apps to target “openstack clouds”), there
>> is a huge need to know what is going to be there consistently when
>> encountering an openstack powered cloud in the wild, whether public or
>> private.  
>> >
>> > So many things happen before that cloud is deployed that the
>> developer is targeting, like the extremely active upstream development
>> where rapid innovation is happening, downstream to distributions that
>> are productizing that code (sometimes a subset of capabilities and
>> code), down to operators who are taking those distros/products to
>> stand up and run services based on them (for internal customers in
>> private, or external in public cloud), all along the way making
>> decisions about what is suitable for their customers/markets.  This
>> creates a lot of diversity in the real world deployments, which is a
>> double edged sword. 
>> >
>> > The question is how do we ensure that what comes out at the end of
>> that long supply chain (for lack of a better word) is of the highest
>> quality, most relevant, and very consistently applied so that this
>> developer building “cloud apps” can choose any “openstack cloud” they
>> want (internal or external) and get a great, consistent experience.
>>  And one that isn’t likely to break the compatibility of their apps as
>> that service provider updates to new versions of openstack.
>> >
>> > This is why there has always been a sense that the technical
>> community, represented by the TC, are as well positioned as anyone to
>> weigh in on these decisions about what would ideally happen
>> downstream.  It’s easy to dismiss this as “just about commercial
>> questions and trademarks, leave it to the board” but look at it
>> another way… someone like Rackspace takes the code from trunk and puts
>> it into production (this is a gross oversimplification I know).  This
>> is not about making a product per se, it’s about standing up a service
>> that people will rely on.  How important is it that a public cloud
>> like that has Keystone capabilities? What about the Code?  To the end
>> user… end user, again, meaning someone who is really the customer/user
>> of the cloud service itself, who who likely cares deeply about API
>> changes that break capability.  What else do they care about, and how
>> do our decisions around defcore take those things into consideration?
>> >
>> > I do think that as the footprint of OpenStack clouds has grown, we
>> haven’t necessarily kept up in terms of engaging with this “end user
>> developer” class, and admittedly the TC is focused on the developers
>> writing openstack not using the clouds based on it per se.  We do have
>> several efforts underway to put more focus on engaging with that
>> aspect of the community and getting that voice into the mix.  There is
>> a new working group spinning up, a dedicated track at the Atlanta and
>> Paris Summits, developer.openstack.org WIP, new questions on the user
>> survey, and at the foundation we are likely to hire a dedicated
>> community manager for this area in the near future. In the meantime,
>> any developers who have a perspective on this, please speak up!  Big
>> decisions are looming and I think we do need to have all stakeholders
>> voicing their opinions leading up to imminent board vote.
>> >
>> > Thanks to everyone who keeps pushing on this topic to put us in the
>> best position to serve our users in 2015 and beyond!
>> >
>> >
>> >
>> >> On Sep 2, 2014, at 1:17 PM, Alan Clark <aclark at suse.com> wrote:
>> >>
>> >> All,
>> >>
>> >> There is another aspect to Designated Sections that I feel is
>> important and I hope not being missed.  At least It's an aspect that
>> I'm looking for from designated code sections.   Perhaps it simply
>> didn't surface in the call last week because it is easier to identify
>> through other projects than those discussed on the call.
>> >>
>> >> Back in the 'spider' discussions, one of the tensions identified
>> was the need to not inhibit developers ability to innovate, while
>> through the use of the OpenStack mark conveying code maturity,
>> completeness and long term stability.  People developing applications,
>> deploying and administrating OpenStack are keen to understand what and
>> which features they can confidently write to and deploy, aka features
>> that are mature, complete and will be sustainable for many future
>> releases. Icehouse had close to 400 new features, Juno will have a
>> similar amount. In fact I don't see that slowing down in any near
>> future.  That shows great innovation! Yet even though we have declared
>> that the integrated projects are ready for release, we know that not
>> all of the features fit the "mature, complete and long term
>> supportable" category.  Several of the blueprints even explicitly make
>> that declaration.  
>> >>
>> >> We don't want to block those. In fact the exact opposite, we want
>> more. The beauty of enabling and including innovative features is for
>> people to try them out and provide feedback and experience to the
>> community.
>> >>
>> >> But let's not miss the opportunity to also tell the ecosystem about
>> those areas that are mature and dependable. We have a ton of features
>> that fit that category. We need to identify those. The creation of
>> capabilities helps but is not complete. This is best resolved through
>> the creation of designated sections.   And that is why the TC is
>> critical for the DefCore effort.  As Thierry delineates, asking the TC
>> and PTLs opinion on  what code is business necessary is not the right
>> question.
>> >>
>> >> In my opinion, asking the PTLs and TC which code features /
>> segments are mature, complete, sustainable and part of the long term
>> vision is the right question to ask.
>> >>
>> >> Regards,
>> >>
>> >> AlanClark
>> >>
>> >>
>> >>>>> On 8/29/2014 at 01:06 AM, Thierry Carrez <thierry at openstack.org>
>> wrote:
>> >>>
>> >>> Rob_Hirschfeld at Dell.com wrote:
>> >>>>
>> >>>>   * Review DefCore Process Chart (attached) * time limited.
>> >>>>
>> >>>>   * Review Designated Sections Strawman
>> >>>> from https://etherpad.openstack.org/p/DefCoreLighthouse.5   
>> >>>
>> >>>
>> >>> The call yesterday was a bit busy, but I think we actually clarified
>> >>> something with respect to the "technical community input on
>> designated
>> >>> sections" stage.
>> >>>
>> >>> There are two types of proposals in the Designated Sections strawman.
>> >>> Some projects have /some/ designated sections, while some others
>> don't
>> >>> have *any* designated section. In the latter case, at the heart of
>> that
>> >>> decision is the fact that a lot of companies in the OpenStack
>> ecosystem
>> >>> ship products that do not include the project at all, and Defcore
>> would
>> >>> still like to allow those companies to use the "Powered by OpenStack"
>> >>> trademark license program. I totally respect those decisions: it's a
>> >>> hard call to make and it's the board prerogative and duty to make it.
>> >>>
>> >>> But as far as technical feedback is concerned, it's difficult to ask
>> >>> Swift contributors if they agree that none of the code they wrote is
>> >>> necessary to call your product "powered by OpenStack". Of course they
>> >>> won't agree: it's actually not a judgment of technical value, it's
>> just
>> >>> a trademark policy choice. By extension, it's difficult to ask the
>> >>> Technical Committee, the body representing all those contributors, to
>> >>> agree that part of the code they produce is not necessary or less
>> >>> important. That body can only give one answer, and will continue
>> to do so.
>> >>>
>> >>> Now, that doesn't mean you can't get any technical input on the
>> >>> Designated sections strawman, but quite the opposite: it just has
>> to be
>> >>> organized differently. There is still a lot of value in technical
>> input
>> >>> to precisely define desi
>> >>
>> >> gnated sections lines in the case a project has
>> >>>
>> >>> /some/ designated sections. For example for Glance, does it make
>> >>> technically sense to consider the WSGI framework as replaceable or
>> not.
>> >>>
>> >>> So here would be my suggested way forward: for all the projects that
>> >>> have "some" designated sections (Nova, Glance, Cinder), organize a
>> >>> specific call/meeting calling all interested members of our technical
>> >>> community (individual TC members, project PTL, any contributor
>> >>> interested) to join and give feedback on the proposed split between
>> >>> designated and non-designated code in their project. That could be a
>> >>> 30-min-per-project thing in a 90-min time span, or 3 separate
>> meetings.
>> >>>
>> >>> FWIW, personally, I think the proposed split on Nova, Glance and
>> Cinder
>> >>> makes technical sense.
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Defcore-committee mailing list
>> >> Defcore-committee at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
>> >
>> >
> 
> 
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


-- 
Thierry Carrez (ttx)