> > 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend