Open Stack

Thanks, Joseph, Rafael for the great comments. Understanding the user's
use-cases is a very important step to make a feature alive.

On Thu, May 9, 2019 at 10:33 AM Joseph Davis <joseph.davis at suse.com> wrote:

> On 5/8/19 5:45 PM, Rafael Weingärtner wrote:
> <snip>
>
> Thanks for the reply Joseph,
>
> I have seen the commit message, and I also read the blog you referenced
> (and other pages related to the same topic) which made us a bit worried. I
> will try to explain our perspective and impressions when we read those blog
> pages. It is also worth noting that we have just started engaging with the
> OpenStack community (so, pardon my ignorance with some parts of OpenStack,
> and how this OpenSource community works). We are already making some
> contributions to Kolla-ansible, and we want to start to contribute back to
> Telemetry as well.
>
> Before getting to the topic of Telemetry, and to be more precise,
> Ceilometer, let me state that I have taken part in other OpenSource
> projects and communities before, but these communities are managed by a
> different organization.
>
> So, Ceilometer; when we were designing and building our OpenStack Cloud,
> where billing is a crucial part of it. Ceilometer was chosen because it
> fits our requirements, working "out of the box" to provide valuable data
> for billing in a high availability fashion. It for sure lacks some
> features, but that is ok when one works with OpenSource. The pollers and
> event managers we are missing, we would like to create and contribute back
> to the community.
>
> Having said that, what puzzled me, and worried us, is the fact that
> features that work are being removed from a project just because some
> contributors/committers left the community. There wasn't (at least I did
> not see) a good technical reason to remove this feature (e.g. it does not
> deliver what is promised, or an alternative solution has been created
> somewhere and effort is being concentrated there, nobody uses it, and so
> on). If the features were broken, and there were no people to fix it, I
> would understand, but that is not the case. The feature works, and it
> delivers what is promised. Moreover, reading the blog you referenced does
> not provide a good feeling about how the community has managed the event
> (the project losing part of its contributors) in question. OpenSource has
> cycles, and it is understandable that sometimes we do not have many people
> working on something. OpenSource projects have cycles, and that is normal.
> As you can see, now there would be us starting/trying to engage with the
> Telemetry project/community. What is hard for us to understand is that the
> contributors while leaving are also "killing" the project by removing part
> of its features (that are very interesting and valuable for us).
>
> Yeah, the history of Telemetry is a bit unusual in how it developed, and I
> could give editorials and opinions about decisions that were made and how
> well they worked in the community, but I'll save that for another time.  I
> will say that communication with the community could have been better.  And
> while I think that simplifying Ceilometer was a good choice at the time
> when the number of contributors was dwindling, I agree that cutting out a
> feature that is being used by users is not how OpenStack ought to operate.
> And now I'm starting to give opinions so I'll stop.
>
> I will say that it may be beneficial to the Telemetry project if you can
> write out your use case for the Telemetry stack and describe why you want
> Events to be captured and how you will use them.  Describe how they
> important to your billing solution (*), and if you are matching the event
> notifications up with other metering data.  You can discuss with the team
> in the meeting if that use case and set of requirements goes in Storyboard
> or elsewhere.
>
> (*) I am curious if you are using CloudKitty or another solution.
>
>
> Why is that important for us?
> When we work with OpenSource we now that we might need to put effort to
> customize/adapt things to our business workflow, and we expect that the
> community will be there to receive and discuss these changes. Therefore, we
> have predictability that the software/system we base our business will be
> there, and we can contribute back to improve it. An open source community
> could and should live even if the project has no community for a while,
> then if people regroup and start to work on it again, the community is able
> to flourish.
>
> I'm really glad you recognize the benefits of contributing back to the
> community.  It gives me hope. :)
> <snip>
>
>
> It is awesome that you might have a similar spec (not developed yet) for
> Monasca, but the question would remain for us. One, two, or three years
> from now, what will happen if you, your team, or the people behind this
> spec/feature decide to leave the community? Will this feature be removed
> from Monasca too?
>
> Developers leaving the community is a normal part of the lifecycle, so I
> think you would agree that part of having a healthy project is ensuring
> that when that happens the project can go on.  Monasca has already seen a
> number of developers come and go, and will continue on for the foreseeable
> future.  That is part of why we wrote a spec for the events-listener, so
> that if needed the work could change hands and continue with context.  We
> try to plan and get cross-company agreement in the community.  Of course,
> there are priorities and trade-offs and limits on developers, but Monasca
> and OpenStack seem to do a good job of being 'open' about it.
>
> <snip>
>
>
> --
> Rafael Weingärtner
>
>
> joseph
>


-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190509/d09bb767/attachment-0001.html>