Open Stack

Excerpts from Graham Hayes's message of 2018-06-05 16:42:45 +0100:
> 
> On 30/05/18 21:23, Mohammed Naser wrote:
> > Hi everyone:
> > 
> > Over the past week in the summit, there was a lot of discussion
> > regarding StarlingX
> > and members of the technical commitee had a few productive discussions regarding
> > the best approach to deal with a proposed new pilot project for
> > incubation in the OSF's Edge
> > Computing strategic focus area: StarlingX.
> > 
> > If you're not aware, StarlingX includes forks of some OpenStack
> > components and other open source software
> > which contain certain features that are specific to edge and
> > industrial IoT computing use cases.  The code
> > behind the project is from Wind River (and is used to build a product
> > called "Titanium
> > Cloud").
> > 
> > At the moment, the goal of StarlingX hosting their projects on the
> > community infrastructure
> > is to get the developers used to the Gerrit workflow.  The intention
> > is to evenutally
> > work with upstream teams in order to bring the features and bug fixes which are
> > specific to the fork back upstream, with an ideal goal of bringing all
> > the differences
> > upstream.
> > 
> > We've discussed around all the different ways that we can approach
> > this and how to
> > help the StarlingX team be part of our community.  If we can
> > succesfully do this, it would
> > be a big success for our community as well as our community gaining
> > contributors from
> > the Wind River team.  In an ideal world, it's a win-win.
> > 
> > The plan at the moment is the following:
> > - StarlingX will have the first import of code that is not forked,
> > simply other software that
> >   they've developed to help deliver their product.  This code can be
> > hosted with no problems.
> > - StarlingX will generate a list of patches to be brought upstream and
> > the StarlingX team
> >   will work together with upstream teams in order to start backporting
> > and upstreaming the
> >   codebase.  Emilien Macchi (EmilienM) and I have volunteered to take
> > on the responsibility of
> >   monitoring the progress upstreaming these patches.
> > - StarlingX contains a few forks of other non-OpenStack software. The
> > StarlingX team will work
> >   with the authors of the original projects to ensure that they do not
> > mind us hosting a fork
> >   of their software.  If they don't, we'll proceed to host those
> > projects. If they prefer
> >   something else (hosting it themselves, placing it on another hosting
> > service, etc.),
> >   the StarlingX team will work with them in that way.
> > 
> > We discussed approaches for cases where patches aren't acceptable
> > upstream, because they
> > diverge from the project mission or aren't comprehensive. Ideally all
> > of those could be turned
> > into acceptable changes that meet both team's criteria. In some cases,
> > adding plugin interfaces
> > or driver interfaces may be the best alternative. Only as a last
> > resort would we retain the
> > forks for a long period of time.
> 
> I honestly think that these forks should never be inside the foundation.
> If there is a big enough disagreement between project teams and the
> fork, we (as the TC of the OpenStack project) and the board (of
> *OpenStack* Foundation) should support our current teams, who have
> been working in the open.
> 
> There is plenty of companies who would have loved certain features in
> OpenStack over the years that an extra driver extension point would
> have enabled, but when the upstream team pushed back, they redesigned
> the feature to work with the community vision. We should not reward
> companies that didn't.

I can understand that point of view. I even somewhat agree. But
saying that we don't welcome contributions now, because they didn't
do things the right way when someone else was in charge of their
project, doesn't strike the right tone for me.

The conversations I've had with the folks involved with StarlingX
have convinced me they have learned, the hard way, the error of a
closed-source fork and they are trying to do better for the future.
The first step of that is to bring what they already have out into
the open, where it will be easier to figure out what can be introduced
into projects to eliminate the forks, what can be discarded, and
what will need to be worked around.

When all of this is done, a viable project with real users will be
open source instead of closed source. Those contributors, and users,
will be a part of our community instead of looking in from the
outside. The path is ugly, long, and clearly not ideal. But, I
consider the result a win, overall.


> 
> > From what was brought up, the team from Wind River is hoping to
> > on-board roughly 50 new full
> > time contributors.  In combination with the features that they've
> > built that we can hopefully
> > upstream, I am hopeful that we can come to a win-win situation for
> > everyone in this.
> > 
> > Regards,
> > Mohammed
> > 
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
>