Open Stack

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)