[openstack-dev] [all] [tc] "No Open Core" in 2016
thierry at openstack.org
Wed Feb 10 16:35:19 UTC 2016
Chris Dent wrote:
> Observing this thread and "the trouble with names" 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