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

Clint Byrum clint at fewbar.com
Wed Feb 10 17:05:45 UTC 2016

Excerpts from Thierry Carrez's message of 2016-02-10 08:35:19 -0800:
> 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.

What you say above resonates with me Thierry, I think this is a gray area,
and I think we have a TC to provide well informed value judgments for
this gray area while we seek to bring the dark and light sides closer
together so there are fewer shades of gray to judge.

For what it's worth, I think Poppy is perhaps soundly in the very middle
of the gray area. There's nothing about it that smells like a poorly
behaved free rider grab for free development resources, nor does it feel
like a lock-in attempt. It legitimately feels like something that
enables OpenStack users to consume services that sit outside of OpenStack.

So, for me, the users are served by this project developing closely with
OpenStack, even if there's no viable free way to consume it. I think
Neutron tap danced through this gray area early on, and now has reached
a point where it is clearly in the light side of things, with _multiple_
free drivers that are completely viable. So, let's let Poppy tap dance,
and let's keep making sure our TC is well informed and makes thought
out decisions like this one, even if they are hard.

More information about the OpenStack-dev mailing list