[os-infrastructure] Re: [os-engineering] Model
discussion boileddry(er)
David Tondreau
david.tondreau at ingres.com
Fri Jun 27 06:57:35 PDT 2008
Hi Deb,
Thanks for adding the insights at RedHat. This is very useful. I have
more questions, though.
You said there was some concern about the implementation of Fedora in
terms of not being able to attract enough people to contribute. Did
those concerns bear out? Was there a point at the launch of Fedora
where some people looked at it and said: "This is the end."? How is
the move seen there now? What is the view of Fedora from inside the
walls at RedHat?
The Fedora project seems to have strong independent leadership and a
sizable community team. You say that there are RH people that work on
Fedora but the externally visible support of Fedora by RedHat is almost
non-existent. Go to fedoraproject.org and about the only reference to
RedHat is a reference that they are a project sponsor (along with 5
other big names) and even that information is hard to find. Is that
because it is hard to build a "community" around a product that is
perceived to be controlled by a commercial, for-profit entity?
Finally, what do you think the relationship is of all these lessons to
Ingres Corp.? We are the same and yet you could argue that we are very
different. We have two models now with the DBMS and OpenROAD. Can we
afford that or do we need to coalesce on one model and one vision for
the community?
David
On 06/27/2008 09:39 AM, Deb Woods wrote:
> One thing to keep in mind with a model such as the Fedora/ RH model is
> ...It takes LOTS of people with the separate stream. There is more
> integration work, QA work etc to work in this environment. When RH went
> this direction, there was a big concern on if they could attract enough
> people to contribute and maintain fedora and not have it all powered by
> RH. RH development is done there and then they integrate back to RHEL
> the pieces that are ready and have relevance to their offerings. Patches
> and security fixes are done to RHEL as well vs Fedora. There are
> individuals that only work in RHEL (sustaining staff, integration and
> QA) and there are people that work in both.
> deb
>
> -----Original Message-----
> From: opensource-infrastructure-bounces at lists.ingres.com
> [mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
> David Tondreau
> Sent: Friday, June 27, 2008 8:09 AM
> To: Andrew Ross
> Cc: Open Source Engineering; Discussions about the infrastructure needed
> to support a trueopensourcecommunity
> Subject: [os-infrastructure] Re: [os-engineering] Model discussion
> boileddry(er)
>
> Andrew,
>
> I don't think the folks at RedHat thought the Fedora "fork" was bad. I
> think they thought it was very calculated, coordinated and essential to
> the business. The kind of "bad" fork that you are talking about is when
>
> a completely separate organization takes a project and permanently
> separates a copy of the code from its parent without any intent to ever
> cross-pollinate. I would argue that this is not *bad* at all -- its
> simply a characteristic of open source -- a risk you run when you choose
>
> the model. If you think you can handle the fork, go for it! Moreover,
> all one needs to do is look at how many variants there are of Linux
> itself to see that forking is common and successful. There are as many
> examples of derivative projects being successful as well (e.g., Postgres
>
> > EnterpriseDB), depending, of course, on how you define "success."
>
> In fact, the basic idea that Ingres is open source and can be forked is
> one of the aspects of our viability. That is, customers may find it
> easier to buy Ingres now that it is open source because its not a
> proprietary technology. Even if Ingres Corp goes away, the software
> lives on and someone could step in and fill the void. We will find in
> the long term that if we encourage the community to not only participate
>
> but actually become responsible, we could see vibrant development occur
>
> around our technologies. If we try to hold it close, what we actually
> encourage is a non-coordinated fork.
>
> To be candid, *none* of the proposals we are talking about will achieve
> the separation that is necessary in the long term (though Steve's model
> is closest to it) for the simple reason that it is *we* who are talking
> about how the community source will be managed. The foundational
> principal of the Fedora model is that the community edition is not *for*
>
> the community, it *belongs* to the community. In the long run, with the
>
> Fedora model, the community will decide how the community code is
> managed.
>
> This is what I was referring to when I talked in my "Truths" post about
> open source being harder than we ever imagined if we embrace it.
> Someone said earlier that we will need lots of people just to perform
> cross-integrations. Yep. In fact, that is what the engineering will
> tend to migrate to (over the years). Certainly, you will have
> developers inside the walls who innovate and contribute to the core
> product. As Deb has explained it to me, there is still quite a bit of
> innovation that occurs at RedHat. But the foundation that the company
> makes money on is integration, quality assurance, stability and support.
>
> From a developer's perspective, do I like this idea? Personally, no.
> I like to think I'm pretty smart and know my technology (and what to do
> with it) better than anyone else. Unfortunately, the sprints are
> beginning to teaching me I may be wrong in that assumption. In any
> case, whether I like it or not is irrelevant because I like my paycheck
> too. What we *have* to do is figure out a way to do is grow the
> community and be commercially successful. The reality is that RedHat is
>
> the most successful open source company on the block. I simply cannot
> see how we cannot adopt the practices that made them successful.
>
> The Fedora model is not just about code lines, its part of the
> go-to-market strategy. How the code is managed simply falls out of this
>
> strategy. Is deciding strategy above us? I don't know. It could be
> that OpenROAD is completely unimportant to senior management. So much
> so that when the OpenROAD team chose the Fedora model because that was
> the only way we saw it could work and proposed the Empire project, it
> was "Yawn, OK, do whatever you want." Or, as you have pointed out
> before, perhaps we are expected to lead the company and *be part of the
> formulation of its strategy*. I am beginning to believe this is the
> case.
>
> David
>
>
> On 06/27/2008 06:59 AM, Andrew Ross wrote:
>
>> Hi Bodo,
>>
>> I understand this important difference in philosophy. It comes down to
>> how strong "gravity" (the propensity to keep content integrating to
>>
> the
>
>> trunk) is. A key principle in open source has always been that forking
>> code is bad. It's part of open source culture and cited in many
>>
> research
>
>> papers on open source as a source of strength. This is why I feel we
>> should structure our environment/model to encourage integration.
>>
>> I understand why people feel allowing the community to diverge is
>> important. I feel the branches-are-cheap-so-go-for-it philosophy of
>> proposal 1 accommodates this. For example, in proposal 1, if another
>> branch was created that Ingres the company does not control or say
>>
> what
>
>> goes in to it, doesn't that satisfy the desire to provide a place
>>
> where
>
>> community can decide on the content? Please see the community release
>>
> 1
>
>> branch in the diagram:
>>
> http://community.ingres.com/wiki/Community_Model
>
>> Do you agree?
>>
>> Andrew
>>
>> -----Original Message-----
>> From: Bodo Bergmann
>> Sent: June 27, 2008 4:11 AM
>> To: Andrew Ross; Discussions about the infrastructure needed to
>>
> support
>
>> a true opensourcecommunity
>> Cc: Open Source Engineering
>> Subject: RE: [os-engineering]FW: [os-infrastructure] Re: Model
>> discussionboileddry(er)
>>
>>
>> Andrew,
>>
>> you wrote:
>> "The proposal 1 model is optimized for keeping the code synchronized
>> rather than optimizing it for scenarios where it needs to fork.
>> There's an implicit assumption that the latter is going to happen less
>> often."
>>
>> If you start from this assumption I understand why you are fighting
>>
> for
>
>> it.
>> This might be true for bug fixes.
>>
>> But in a vibrant community I see it rather the opposite way:
>> There will be many changes to existing fetures and a lot of new
>>
> features
>
>> (the Development Sprint in London just showed this).
>> The community will decide what's going to be the community release.
>> Example:
>> If the community decides to change some code which would tremendously
>> improve the performance of the community version (doesn't matter if
>>
> it's
>
>> Ingres or OpenROAD or whatever), but which would e.g. rip off backward
>> compatibility for the enterprise version or violate B1 security, then
>> with proposal 2 (or 3 - made by Steve), this would be possible wheras
>> with proposal 1 it would have to be rejected by Ingres Corp.
>> with the argument "It brings problems for our enterprise version".
>> Steve mentioned "Project D" as another example.
>> Such rejections will add a "nice" subtitle to our Open Source
>>
> community
>
>> commitment statement:
>> "as long at it serves us".
>>
>> I want the community to decide for itself what they need, we don't
>>
> have
>
>> to be the wise guys who tell the community what's best for them (and
>> us).
>> That doesn't mean we are off the field. We will still support the
>> community, guide, teach & help them, let them know about the
>> implications of the changes, etc.
>> But in the end there will be some kind of community committee which
>>
> will
>
>> have the say.
>> A vibrant community will serve us better and eventually come up with
>> more innovative solutions than one which is permanently dominated and
>> patronized by Ingres Corp.
>>
>> That's why
>> Bodo.
>>
>> -----Original Message-----
>> From: opensource-engineering-bounces at lists.ingres.com
>> [mailto:opensource-engineering-bounces at lists.ingres.com] On Behalf Of
>> Andrew Ross
>> Sent: Friday, June 27, 2008 3:50 AM
>> To: Discussions about the infrastructure needed to support a true
>> opensourcecommunity
>> Cc: Open Source Engineering
>> Subject: RE: [os-engineering]FW: [os-infrastructure] Re: Model
>> discussionboileddry(er)
>>
>> Hi Joe,
>>
>> This looks like the way it works today in piccolo, and has been that
>>
> way
>
>> for a while. Have I misunderstood? If someone made a change to dm2r.c
>>
> in
>
>> r2, and propped it to r3 by way of main (or made the change in main
>>
> and
>
>> patched it to r3), then any feature content or bug fixes affecting
>> dm2r.c in main will always have to be contended with.
>>
>> For clarity, with proposal 1, it is possible to have content in
>>
> piccolo
>
>> (or call it a protected branch in any scs) that is not available to
>>
> the
>
>> public. These changes are not reflected back into main unless
>>
> explicitly
>
>> propped.
>>
>> In general, I'm reading what you've wrote what do we do when we have
>>
> to
>
>> fork certain files for good reason and how to deal with the complexity
>> it could cause. (please let me know if I've misunderstood) The
>>
> proposal
>
>> 1 model is optimized for keeping the code synchronized rather than
>> optimizing it for scenarios where it needs to fork. There's an
>>
> implicit
>
>> assumption that the latter is going to happen less often.
>>
>> The alternative model (pending the diagram to ensure I understand it
>> 100%) looks like someone would have to manually cherry pick & prop
>> content to either side to allow community and enterprise to benefit
>>
> from
>
>> each other. This may even have to be a team of people as it's likely
>>
> no
>
>> one person has domain expertise necessary to make the call.
>>
>> Andrew
>>
>> -----Original Message-----
>> From: opensource-infrastructure-bounces at lists.ingres.com
>> [mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf
>>
> Of
>
>> Joe Abbate
>> Sent: June 26, 2008 9:12 PM
>> To: Chris M. Clark
>> Cc: Open Source Engineering; Discussions about the infrastructure
>>
> needed
>
>> to support a true open sourcecommunity
>> Subject: Re: [os-engineering]FW: [os-infrastructure] Re: Model
>> discussionboiled dry(er)
>>
>> Hi Chris,
>>
>> Chris Clark wrote:
>>
>>
>>> Coming back to the hypothetical DMF change, this should be done in a
>>> public experimental branch, the issue would be if this experiment is
>>> considered a success and if we cross/merge/integrate it into "Main
>>> Community Mirror". This would then end up in main and future
>>> Enterprise Branches, I don't think it would be integrated into
>>> existing commercial branches (they are supposed to be feature
>>> complete, support should only be integrating bug fixes into existing
>>> commercial branches).
>>>
>>>
>> But what I think that the proponents of the "fresh", single
>> ingres!main/svn:main fail to realize is that say the new access method
>> (NAM) adds a new file, back/dmf/dmp/dm1nam.c and adds calls to the new
>> functions in back/dmf/dmp/dm2r.c. With the immediate, unbuffered
>> approach, those changes would presumably move from the experimental
>> branch to svn:main and immediately update Piccolo's ingres!main. No
>> problem yet. Now someone makes a fix to dm2r.c in ingres!ingres2006r2
>> and needs to propagate it to ingres!ingres2006r3. If it overlaps the
>> NAM calls, he/she is forced to work around the NAM changes when
>> integrating the fix into ingres!main and then ensure he/she doesn't
>> propagate any of the NAM changes into ingres2006r3. With the
>> "controlled", "buffered" approach the fix can flow from 2006r2 to main
>> to 2006r3 as usual because main doesn't have the NAM changes.
>>
>> The same applies in the other direction. Just do a p describe -sfiles
>> 469243 to see the number of files that had B1 code in them. If we add
>> them back into ingres!main, in the immediate, unbuffered model, the
>> files would be publicly available at
>> http://code.ingres.com/ingres/main/src/. Even if the latter is made
>> into a private repository, how does a subsequent ingres2006r2 change
>>
> to
>
>> adtcompute.c get propagated to the public community codeline?
>>
>> Joe
>> _______________________________________________
>> opensource-infrastructure mailing list
>> opensource-infrastructure at lists.ingres.com
>> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
>> _______________________________________________
>> opensource-engineering mailing list
>> opensource-engineering at lists.ingres.com
>> http://lists.ingres.com/mailman/listinfo/opensource-engineering
>> _______________________________________________
>> opensource-engineering mailing list
>> opensource-engineering at lists.ingres.com
>> http://lists.ingres.com/mailman/listinfo/opensource-engineering
>>
>>
>>
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
>
>
More information about the opensource-infrastructure
mailing list