> -----Original Message----- > From: Stefano Maffulli [mailto:stef...@openstack.org] > Sent: 12 March 2015 00:26 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] Avoiding regression in project governance > > On Wed, 2015-03-11 at 17:59 -0500, Ed Leafe wrote: > > The longer we try to be both sides of this process, the longer we will > > continue to have these back-and-forths about stability vs. innovation. > > If I understand correctly your model, it works only for users/operators who > decide to rely on a vendor to consume OpenStack. There are quite large > enterprises out there who consume directly the code as it's shipped from > git.openstack.org, some from trunk others from the stable release .tgz: > these guys can't count on companies A, B, C or D to put resources to fix their > problems, because they don't talk to those companies. > > One thing I like of your proposal though, when you say: > > > So what is "production-ready"? And how would you trust any such > > designation? I think that it should be the responsibility of groups > > outside of OpenStack development to make that call. > > This problem has been bugging the European authorities for a long time and > they've invested quite a lot of money to find tools that would help IT > managers of the public (and private) sector estimate the quality of open > source code. It's a big deal in fact when on one hand you have Microsoft and > IBM sales folks selling your IT managers overpriced stuff that "just works" > and on the other hand you have this "Linux" thing that nobody has heard of, > it's gratis and I can find it on the web and many say it "just works", too... > crazy, right? Well, at the time it was and to some extent, it still is. So > the EU > has funded lots of research in this area. > > One group of researcher that I happen to be familiar with, recently has > received another bag of Euros and released code/methodologies to evaluate > and compare open source projects[1]. The principles they use to evaluate > software are not that hard to find and are quite objective. For > example: is there a book published about this project? If there is, chances > are this project is popular enough for a publisher to sell copies. Is the > project's documentation translated in multiple languages? > Then we can assume the project is popular. How long has the code been > around? How large is the pool of contributors? Are there training programs > offered? You get the gist. > > Following up on my previous crazy ideas (did I hear someone yell "keep 'em > coming"?), probably a set of tags like: > > book-exists (or book-chapter-exists) > specific-training-offered > translated-in-1-language (and its bigger brothers translated-in-5, > translated-in-10+languages) > contributor-size-high (or low, and we can set a rule as we do for the > diversity metric used in incubation/graduation) > codebase-age-baby, -young and -mature, (in classes, like less than 1, > 1-3, > 3+ years old) > > would help a user understand that Nova or Neutron are different from > (say) Barbican or Zaqar. These are just statements of facts, not a qualitative > assessment of any of the projects mentioned. At the same time, I have the > impression these facts would help our users make up their mind. > > Thoughts?
Just one, is it too late to change the name, tag is pretty overloaded and I rather like the sound of badge. I would be nice to see project working towards different new badges and carrying them proudly after earning them. Oh another one, I'm not convinced that 3+ years is still mature project. I think there is room to look bit out of our own sandbox and think where we are in 2, 3 or 5 years time. Perhaps we need to change the governance again, perhaps this could be something that is flexible all the way there, but I would hate to call Nova, Swift, Glance etc. "ancient" or "granny" just because they have been around double/triple the mature time. - Erno > > [1] > http://www.ict-prose.eu/2014/12/09/osseval-prose-open-source- > evaluation-methodology-and-tool/ __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
