[openstack-dev] [all] [tc] "No Open Core" in 2016

Thierry Carrez thierry at openstack.org
Wed Feb 10 16:35:19 UTC 2016

Chris Dent wrote:
> [...]
> Observing this thread and "the trouble with names"[1] one I get
> concerned that we're trending in the direction of expecting
> projects/servers/APIs to be done and perfect before they will ever
> be OpenStack. This, of course, runs entirely contrary to the spirit
> of open source where people release a solution to their itch and
> people join with them to make it better.
> If we start thinking of projects as needing to have "production-grade"
> implementations and APIs as needing to be stable and correct from
> the start we're backing ourselves into corners that are very difficult
> to get out of, distracting ourselves from the questions we ought to be
> asking, and putting barriers in the way of doing new but necessary
> stuff and evolving.

I certainly didn't intend to mean that projects need to have a final API 
or perfect implementation before they can join the tent. I meant that 
projects need to have a reference implementation using open source tools 
that has a chance of being used in production one day. Imagine a project 
which uses sqlite in testing but requires Oracle DB to achieve full 
functionality or scaling beyond one user: the sqlite backend would be a 
token open backend for testing purposes but real usage would need you to 
buy into proprietary options. That would certainly be considered "open 
core": a project that pretends to be open but requires proprietary 
technology to be "really used".

Now it's not that clear cut and a lot of things fall in the grey area: 
on one side you have proprietary backends that may offer better 
performance -- at which point should we consider that "better 
performance" means nobody would seriously use the open source backend ? 
On the other side you have corner cases like Poppy where the 
"proprietary service" it plugs into is difficult to replicate since it's 
as much physical infrastructure than software.

Thierry Carrez (ttx)

More information about the OpenStack-dev mailing list