Re: [HACKERS] Increased company involvement

From: Magnus Hagander
Subject: Re: [HACKERS] Increased company involvement
Date: ,
Msg-id: 6BCB9D8A16AC4241919521715F4D8BCE6C73BC@algol.sollentuna.se
(view: Whole thread, Raw)
List: pgsql-advocacy

> > > However, there was a lot of coordination that happened
> with Fujitsu
> > > that I don't see happening with the current companies involved.
> > > Companies are already duplicating work that is also done by
> > > community members or by other companies.
> >
> > That is why we have 80 Linux distributions and a dozen FreeBSD
> > distributions (can I include MacOSX?).
>
> I guess more aprropriate comparison would be to distibution
> specific linux kernels, i.e. RedHat linux kernel vs. suse
> linux kernel v.s.
> "vanilla" or "real" :) linux kernel.

As someone who has been bitten by the RH vs SuSE vs kernel.org kernel
several times over the past couple of  weeks, we should *really* try to
avoid this as much as possible. It's a *major* hassle for the end user
if postgresql is no longer the same as postgresql.

Not exactly sure what to do to avoid it, though ;-) Other than encourage
the companies that develop extensions to submit these to the community
distribution and work to get them accepted there...


> > I can see this as an issue but sometimes that community is
> a hampering
> > course as well. I recognize the community goals and respect
> them but
> > in some things the community can move really slow. From what I can
> > tell some of this is caused by the no new features rules etc...
> >
> > In business moving slow can mean death to a project.
> >
> > Which is why (hate to beat a dead horse) many OSS projects
> have moved
> > to 6 month release cycles.
>
> Well, it is a two-sided thing. On one hand, businesses
> usually need new features "yesterday", but on the other hand,
> business would loose most of the benefit of getting the
> feature fast, if it is not included in the main branch along
> the road, preferrably in the next official release, because
> said business would be dependent of the implementor of his
> specific feature for integrating _all_ other new and
> desirable fetures of next releas in their specific version of
> postgres.

An example of this might be Powergres - not sure if it was planned to go
into community ever, but it must be a pain to maintain the threaded
version alongside the main one. I guess that's why it's still based on
7.3...


//Magnus


pgsql-advocacy by date:

From: Josh Berkus
Date:
Subject: Re: Need help on drivers, add-ons
From: Brennan Stewart
Date:
Subject: GUITools update