On 02/05/2016 12:14 PM, Ryan Brown wrote: > On 02/05/2016 05:57 AM, Thierry Carrez wrote: >> Hi everyone, >> >> Even before OpenStack had a name, our "Four Opens" principles were >> created to define how we would operate as a community. The first open, >> "Open Source", added the following precision: "We do not produce 'open >> core' software". What does this mean in 2016 ? >> >> Back in 2010 when OpenStack was started, this was a key difference with >> the other open source cloud platform (Eucalyptus) which was following an >> Open Core strategy with a crippled community edition and an "enterprise >> version". OpenStack was then the property of a single entity >> (Rackspace), so giving strong signals that we would never follow such a >> strategy was essential to form a real community. >> >> Fast-forward today, the open source project is driven by a non-profit >> independent Foundation, which could not even do an "enterprise edition" >> if it wanted to. However, member companies build "enterprise products" >> on top of the Apache-licensed upstream project. And we have drivers that >> expose functionality in proprietary components. So what does it mean to >> "not do open core" in 2016 ? What is acceptable and what's not ? It is >> time for us to refresh this. >> >> My personal take on that is that we can draw a line in the sand for what >> is acceptable as an official project in the upstream OpenStack open >> source effort. It should have a fully-functional, production-grade open >> source implementation. If you need proprietary software or a commercial >> entity to fully use the functionality of a project or getting serious >> about it, then it should not be accepted in OpenStack as an official >> project. It can still live as a non-official project and even be hosted >> under OpenStack infrastructure, but it should not be part of >> "OpenStack". That is how I would interpret "no open core" in OpenStack >> 2016. >> >> Of course, the devil is in the details, especially around what I mean by >> "fully-functional" and "production-grade". Is it just an API/stability >> thing, or does performance/scalability come into account ? There will >> always be some subjectivity there, but I think it's a good place to >> start. >> >> Comments ? > > If a project isn't fully functional* then why would we accept it at all? > Imagine this scenario: > > 1) Heat didn't exist > 2) A project exactly like heat applies for OpenStack, that lets you use > templates to create resources to a specification > 3) BUT, if you don't buy Proprietary Enterprise Template Parsing > Platform 9, a product of Shed Cat Enterpise Leopards**, you can't parse > templates longer than 200 characters. > > Would *any* TC count that as a project that could join under our current > system? I don't think so. The TC (and community) would say something > along the lines of "WTF are you thinking? Go read the 4 opens and try > again"
I think it is a point of strength that so many in our community including the TC both individually and collectively are able to communicate perspectives and decisions without referencing profanity. So I happen to disagree with your current characterization as worded. Thank you, Anita. > > I don't think adding "no open core" would change a decision the > future-community and future-tc might make, because they will be elected > by aforementioned community. Adding buzz-requirements like "must be > fully-functional, production grade, webscale open-cloud softwidgets" > isn't going to help future-us. > > Footnotes: > > * in my view, an openstack product that requires you to pay a vendor is > as functional as an openstack product chock-full of syntax errors > > ** Shed Cat Enterprise Leopard is strictly fictional, and not based on > any company that currently or ever has existed. > __________________________________________________________________________ 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
