Peter Eisentraut wrote:
> I don't think trust or scaling or implementation languages are the real issue.
> It has been established that for a variety of reasons, smalls tools that can
> be combined work better than one big tool. That is why the Linux kernel does
> not contain a windowing system.
>
>
I fully agree with this and I'm not suggesting that we create one big tool.
> The issue you are facing is an issue of perception.
Yes, but that's only one part of it.
> There are a number of
> ways to fix that, only one of which is including PL/Java into the PostgreSQL
> source distribution. I was on the other side of the debate when we kicked
> out the JDBC driver, but today I think this was the best thing that could
> have happened, to both sides.
Separate source distributions and delegated responsibilities must be
maintained. I'm a big fan of those. I'm arguing that you can keep them
and still benefit from a more elaborated core organization.
> If you see any measures that we could take to
> make PL/Java look as good in the public eye as the JDBC driver -- certainly
> that is a reasonable comparison -- then I'm sure we can address them.
>
>
We could achieve a number of pros that doesn't relate to perception:
- Far better synergies and incentive to create a coherent portfolio
- More elaborated build farm support
- Common, configurable documentation
- Shared server infrastructure
But perception is of course extremely important. I think that mature and
stable add-on modules that have an established user-base should be
visible as part of PostgreSQL. They should be represented on the
PostgreSQL main web-site and not as links to PgFoundry, Gborg,
Codehause, Sourceforge, and what have you. Important things that relate
to perception is:
- Web site outlook. Seamless navigation between core and add-ons.
- Maintainer. Core or third-party?
- Packaging. Part of core or bundled by commercial or other vendor?
- Status. Stable? Released? (who claims it's stable?)
- Mailing lists. Is it xxx@postgresql.org or something else?
Take a look at the 9 bullets above. Now, given the current organization,
consider the impact of adding versus rejecting an add-on module. I'm
still convinced that the only solution to that dilemma is to change the
organization.
Kind Regards,
Thomas Hallgren
