> > 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 bound to happen no matter what. Look at plJava and plJ. Some
> people just feel that their way is better. Some people just don't get
> along etc...
>
> That is why we have 80 Linux distributions and a dozen FreeBSD
> distributions (can I include MacOSX?).
True enough. And coordination, just like other outward-facing
activities, is often inconvenient and easy to forget. But it's
important. I've just left the Board of Directors of the Web Services
Interoperability organization (WS-I). Coordinating the standards
activities of IBM, MS, Sun, Oracle, BEA, Fujitsu, SAP, and 130 others
takes enormous time and care, but it's the only way coop-etors can
function.
And having said that, aggressive businesspeople will move too quickly at
times, or will hide their activities for business reasons. It's a mostly
forgivable sin, IMO.
> > Second, some developers are being hired from the community to work
on
> > closed-source additions to PostgreSQL. That is fine and great, but
one
> > way to kill PostgreSQL is to hire away its developers. If a
commercial
> > company wanted to hurt us, that is certainly one way they might do
it.
> > Anyway, it is a concern I have. I am hoping community members hired
to
> > do closed-source additions can at least spend some of their time on
> > community work.
>
> I would think that most of the developers would stipulate that in
order
> to take the position??? I know Command Prompt would always make sure
> that the developer could work on the community stuff.
The same is true for EnterpriseDB.
> > And finally, we have a few companies working on features that they
> > eventually want merged back into the PostgreSQL codebase. That is a
> > very tricky process and usually goes badly unless the company seeks
> > community involvement from the start, including user interface,
> > implementation, and coding standards.
>
> I concur with this. We ran into this with plPerl.
The only way to successfully extend PostgreSQL commercially is to
coordinate with the community.
-- Andy