Open Stack

> On Sep 22, 2014, at 2:54 AM, Thierry Carrez <thierry at openstack.org> wrote:
> 
> Radcliffe, Mark wrote:
>>> The situation is actually really, really simple: the TC is responsible
>>> for a set of code repositories collectively known as "the OpenStack
>>> project", which aim to fulfill the OpenStack Mission. Even speaking of
>>> the "Integrated Release" is treading on an implementation detail, which
>>> may prevent further evolution ! The "Core OpenStack Project" is an
>>> historical artifact, and trademark policy now uses much more
>>> quantifiable concepts (like capabilities and designated sections), so I
>>> don't see the value of continuing to mention it in the bylaws themselves.
>>> 
>>> Personally I would just get rid of any mention of "Core OpenStack
>>> Project" and "Integrated release" in the bylaws, and only keep "the
>>> OpenStack Project". That would give us flexibility we need to evolve in
>>> the future, both on the TC side and on the Trademark policy side.
>> 
>> RESPONSE:  Let’s make sure that we remember the background: the Board
>> (and I) agree that the current bylaws are too detailed and too difficult
>> to change. The DefCore process was started by the Board in November to
>> determine how to redefine the process. However, the requirement that
>> changes in the Core require Board approval has been part of the bylaws
>> from the Foundation's beginning (see below). In fact, DefCore is a
>> committee appointed by the Board to determine how to define Core in the
>> future. The Board certainly wants to define those capabilities with the
>> Technical Committee input and has been doing so, so I think that you
>> concern about a disagreement between the Board and the TC are misplaced.
>> However, the Board does have responsibility for trademark policy , if
>> certain code or functionality is required for trademark use,  the Board
>> needs to be able to control any proposed deletion to such
>> code/functions.  For example, if the trademark policy specifies
>> "designated code" and the Technical Committee deprecates that designated
>> code, what does it mean to have a trademark policy?  As I noted to
>> Mark,  in the original bylaws, the Technical Committee did have the
>> exclusive right to make proposals to change the scope of Core.  I
>> included that approach in the draft this summer, but I was told that the
>> Technical Committee was not interested in continuing that approach.  If
>> that view has changed, we should discuss it.
> 
> I think the view of the TC is that we produce a number of projects and
> that at every release, the Board picks subsets of those projects to use
> for various trademark policies. For example, for havana, the board picks
> "designated sections" among the "integrated release" to use with the
> "Powered by OpenStack" trademark. For icehouse, it may pick other
> projects among those we produce. At every release, the TC creates the
> superset and the Board picks the subset(s). The TC is not interested in
> proposing subset(s). And the board should not prevent removals from the
> superset.
> 
> If a given project is abandoned by all developers and no longer part of
> the integrated release, having the board mandate that it's still part of
> the integrated release would be awkward. Now, I understand the intent --
> we don't want to bluntly deprecate / remove items that have become part
> of trademark rules. But the TC has structure in place for deprecation /
> removal of features already (takes at least two cycles), so I think that
> concern can be solved without having the Board step into TC territory in
> the definition of the superset.
> 
>> [...] 
>> We need the three definitions for the following reasons:
>> 
>> 1.      Core OpenStack Project: The parts of the distributed
>> code/capabilities required for trademark use. Since the Board is
>> responsible for the trademark policy, they need input on removing these
>> functions/designated code.
>> 
>> 2.      Integrated Release: The parts of the OpenStack Project (of which
>> the Core OpenStack Project is a subset) which are distributed and need
>> to be under the Apache License version 2.0. The definition of what goes
>> into the Integrated Release is completely in the discretion of the
>> Technical Committee except that it needs to be available under the
>> Apache Software License version 2.0.
>> 
>> 3.      OpenStack Project:  All of the code managed or used by the
>> OpenStack community (of which the Integrated Release and the Core
>> OpenStack Project are subsets) whether distributed or not. The code that
>> is not distributed does not need to be under the Apache Software License
>> version 2.0 which gives the Technical Committee more flexibility.
>> 
>> I don’t understand how defining Integrated Release impinges on
>> implementation details (see above). However, if you can explain the
>> concern, I will work to resolve it.
> 
> I'll expand on my comment. I think that ideally, we would not have to
> change bylaws every time we adapt our processes or trademark license
> programs. Ideally, the language in the bylaws would let us some
> maneuvering room so that we don't constantly have to consider costly
> changes to them (especially around the protected sections). Therefore I
> think the language in the bylaws should avoid unnecessary details as
> much as possible.
> 
> The "Core OpenStack Project" is a detail. It's a subset of projects that
> the future "powered by OpenStack" trademark policy will use. Actually,
> the policy doesn't even mention "core" anymore, but uses "designated
> sections" and "required capabilities", which are much more descriptive.
> What if tomorrow we want to have two trademark policies (add "OpenStack
> compatible") which affect different subsets of projects, and the bylaws
> only define one ? Saying that "the board may pick any subset of the
> OpenStack Project as they deem necessary to use as part of trademark
> license programs definition" gives the board much more room to evolve
> trademark policies in the future without requiring a new bylaws change.
> 
> The name "integrated release" is also a detail. If the projects in the
> release stop being "integrated" or the release becomes staggered, it
> should not prevent the board from picking a subset of it for trademark
> policies. That said, I think we can live with this one being in the
> bylaws, since there will probably always be a concept that we can map to
> it in the future, so it should not really prevent anything from
> happening (or require a bylaws change one year down the road).
> 
> That said, I'm not a lawyer... you certainly know better than I do about
> required language. My concern is about agility. IMHO our bylaws set too
> much in stone, so we can't undertake any change in policy without
> changing them, and it takes a couple of years to do so.

+1 for agility. I think we are already too constrained in our ability to adapt our processes in this changing environment. If we are going to go through the pain of bylaws changes we need room to maneuver as we find the right combination of process and roles. If we are learning anything in the last couple of years it is that agility is required and demanded by the foundation members. In the current structure, it is taking much too long to evolve. Any changes to the bylaws need to move considerably towards making it easier to adapt to changing conditions while clarifying the “separation of responsibilities” as needed among the entities driving us forward (Board, TC, etc.)

> 
> -- 
> Thierry Carrez (ttx)
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee