[os-infrastructure] Re: [os-engineering] Closed source components

[Paul Mason]

One of the things I've noticed about successful open source projects
e.g. Linux, is that whilst the code is available to anyone and anyone
can contribute, there's usually a strong leader who a) has final say on
the direction of the project and b) acts as a strong "gatekeeper" in
terms of code contributions to the "official" version of the codeline.
That leader may be a group, a committee or it may be an individual.
Browse the Linux Kernel mailing list for a while and you'll quickly see
that Linus and his "lieutenants" are very tough on accepting patches. If
you really want the feature/fix/change you can always use your own
branch. If you want it in the official branch then you have to convince
Linus that it's worthwhile and he may make you wait or want you to
re-work it. I've seen a similar thing on the PostgreSQL mailing lists
and elsewhere.

 

Now individuals who've had their patches rejected can and do object to
the "Linus knows best" attitude, but the community as a whole doesn't.
People unite behind strong leadership and anyway there are disadvantages
for everyone in forking.

 

When CA first open-sourced Ingres I always assumed that CA, and now
Ingres Corp, would take that "strong gatekeeper" role for Ingres. We
decide the direction Ingres is going in, if individuals in the community
disagree or have other ideas then they have to convince us. In the
meantime they are always free to create their own branches (or even
forks) but they have the responsibility of keeping in step with the
'official' version. This is no different from the way Linux and many
other open source projects operate.

 

I think if we create a community codeline which has a gatekeeper who is
not Ingres Corp then we've created a fork because whoever is gatekeeping
that code may well take it in a different direction. And that would be
bad because as the forks diverge it will be harder and harder to take
advantage of the contributions on the community side.

 

So I would say the choice is do we want to take the lead over the
direction of Ingres as a whole, or do we want to create a community fork
and only take the lead for the Enterprise version?

 

Cheers

Paul

 

 

 

________________________________

From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Bodo Bergmann
Sent: 01 July 2008 17:28
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Subject: RE: [os-infrastructure] Re: [os-engineering] Closed source
components

 

A "community" branch (branched from the piccolo-main-mirror
"community-main") 

would still allow all the community releases (branched from "community")

to benefit from the Ingres staff input,

but additionally allows to have community-only (non-enterprise) features
in it - without repeated cross-integration and merging

from one community release/project branch to the next.

 

In the end it comes to the question if the main community codeline (from
which community release codelines are branched) is

a) what Ingres Corp. thinks is best for the community (we only accept
your enterprise-ready features) OR

b) what the community thinks it wants - with support/recommendations
from Ingres Corp.
   (decision what goes into the community codeline made by the community
- e.g. by a steering commity,
    but we will only take back enterprise-ready changes to our main
codeline)

 

I don't think OpenSource communities like the "We know what's best for
you!" attitude,

probably it's best to ask the community members.

 

The decision how the community is supposed to do development should not
depend on

the tools used or the synchronization effort required. 

 

Bodo.

 

________________________________

From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Alex Hanshaw
Sent: Tuesday, July 01, 2008 6:02 PM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Subject: RE: [os-infrastructure] Re: [os-engineering] Closed source
components

My answer is yes. community-main is our interface to our piccolo
repositories (for enterprise) and controlled by us.

Ray's diagram shows community release branches from community-main. They
can be anywhere from 100% through to 0% input and control from us.

community-main being controlled does not mean we can not have a
community release that is owned and run by the community.

That said, initially at least, the community is unlikely (IMO) to want
to own a release that has not input from Ingres staff.

 

 Alex

 

________________________________

From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Daryl Monge
Sent: 01 July 2008 16:22
To: Discussions about the infrastructure needed to support a true open
sourcecommunity
Subject: Re: [os-infrastructure] Re: [os-engineering] Closed source
components

 

On Jul 1, 2008, at 10:07 AM, Roger L. Whitcomb wrote:

 

So, Alex, you're saying that Ingres Corp. would retain most of
the authority over what gets into community main??  And based on our
"enterprise-ready" criteria?

 

I can't speak for Alex ( ;-) )  but my preferred answer is yes.  

 

Observations:

            Open Source does not imply giving up ownership and
responsibility of the code

            There is no amorphous blob of community out there that will
want big features we don't want

 

So from a pragmatic point of view, I think this is all a "tempest in a
teapot".  We are not going to see some huge demand from the community to
put anything but useful incremental features and bug fixes into the Open
Source head-rev.

 

The Project D example is highly illustrative, but with respect to the
"D" folks,  I do not see the real world clamoring for these types of
projects to be integrated into the mainline.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ingres.com/pipermail/opensource-infrastructure/attachments/20080701/29afccbb/attachment.html