Increased company involvement
I am very excited to see companies involved in PostgreSQL development.
It gives us funding for developers and features that is new for us. We
had Fujitsu funding some features for 8.0 and that really helped us.
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. The big issue is communication. Because the
PostgreSQL code base is common for most of the companies involved, there
has to be coordination in what they are working on and their approaches.
If that doesn't happen, two companies will work on the same feature, and
only one can be added, or a complex process of merging the two patches
into one patch has to happen --- again duplicated effort. I am willing
to do the coordination, or even better, have the companies involved
publicly post their efforts so all the other companies can know what
is happening. I realize this is hard for companies because their
efforts are in some ways part of their profitability. Does
profitability require duplication of effort and code collisions? I am
not sure, but if it does, we are in trouble. I am not sure the
community has the resources to resolve that many collisions.
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.
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 hate to be discouraging here, but I am trying to communicate what we
have learned over the past few years to help companies be effective in
working with open source communities. I am available to talk to any
company that wants further details.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
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?).
The big issue is communication. Because the
PostgreSQL code base is common for most of the companies involved, there
has to be coordination in what they are working on and their approaches.
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.
is happening. I realize this is hard for companies because their
efforts are in some ways part of their profitability.
That is true, there are sometimes strategic reasons to not annouce a
project.
profitability require duplication of effort and code collisions? I am
not sure, but if it does, we are in trouble. I am not sure the
community has the resources to resolve that many collisions.
Which is why you are starting to see forks such as Bizgres but it is
also why you are seeing forks go away (Mammoth PostgreSQL).
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.
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.
Sincerely,
Joshua D. Drake
Command Prompt, Inc.
--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org
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.
You might be interested to know that someone is evening wanting to
sponsor some phpPgAdmin development.
Chris
Joshua D. Drake wrote:
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?).
Do companies want to write for Blue Hat PostgreSQL and Suza PostgreSQL
because that might be what happens if we don't stay organized? In fact,
it might have be happening already.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Do companies want to write for Blue Hat PostgreSQL and Suza PostgreSQL
because that might be what happens if we don't stay organized? In fact,
it might have be happening already.
Well that depends... If the companies are writing for Pervasive
PostgreSQL I don't think they would have a problem with that ;).
And I do agree with you Bruce, it is happening already -- I don't think
there is any question in that.
Sincerely,
Joshua D. Drake
--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org
Joshua D. Drake wrote:
Do companies want to write for Blue Hat PostgreSQL and Suza PostgreSQL
because that might be what happens if we don't stay organized? In fact,
it might have be happening already.Well that depends... If the companies are writing for Pervasive
PostgreSQL I don't think they would have a problem with that ;).And I do agree with you Bruce, it is happening already -- I don't think
there is any question in that.
Oh, well good I am not seeing phantoms. I have had time to focus on
where we are for the past few days and I am worried about what I see. It
can be great, or it can be a mess, for both us and the companies
involved, and I want to work to make it the former.
The fact is, we now have more and more companies relying on us to be a
success, and that is an added responsibility for us. We can make it
work, but just hoping for it isn't enough --- we have to focus on the
issues early and plan for that success.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Joshua D. Drake wrote:
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...
Actually, I think that PL/Java versus PL/J is a good example of where
some coordination would have helped a lot.
The short story:
I was between jobs in December 2003 through February the following year.
A lot of work on PL/Java was made during that time. I had no clue that
there was another active project with similar objectives until after my
first fully functional submission to gborg. Had I known, the outcome
would have been different. Today there are ongoing and very active
efforts to collaborate.
The longer story (if anyone is interested):
Before I started PL/Java I informed the community of my intentions (see
hackers thread "pljava revisited"
http://archives.postgresql.org/pgsql-hackers/2003-12/msg00310.php ). I
got a lot of feedback and good advice such as using C instead of C++,
hosting the project at gborg, etc. but nobody told me back then that
there was an active PL/J project. I found traces of that project on
sourceforge but it seemed to have been dead for over a year. At that
time there was no redirect from sourceforge.
Jan Wieck started the thread "PL/Java issues"
http://archives.postgresql.org/pgsql-hackers/2003-12/msg00819.php in
which I made 2 major posts. Nothing in that thread indicated that there
was an ongoing project and I got no reply to my posts. On January the
7th, I made my first submission to gborg.
When I, in mid February, realized that the PL/J project was indeed alive
and active, I wrote the "PL/Java - next step?"
http://archives.postgresql.org/pgsql-hackers/2004-02/msg00713.php where
I outlined possible futures for PL/Java and PL/J. The outcome of that
was that PL/J (Dave Cramer and Laszlo Hornyak) and I had an IRC meeting
where we agreed on some limited collaboration (see "Minutes from Pl/Java
-next step IRC"
http://archives.postgresql.org/pgsql-hackers/2004-03/msg00171.php ).
From that point and until a month or so ago, the active collaboration
between the projects could have been better. Some things did happen
though. Laszlo asked me to publish some PL/Java interfaces in a public
maven repository which I did and we had some discussions. I made an
attempt to have a major sponsor step in and take the lead in a project
aiming to provide a flexible solution where a choice of approach could
be made but the sponsor understandably wanted to wait and see.
Today, we (the PL/Java and PL/J project members) make common efforts to
factor out client tools that indeed can be common to a separate project.
We are also discussing how to make the PostgreSQL user experience as
similar as possible and thus allowing use of PL/Java or PL/J without
changing anything but configuration.
Kind regards,
Thomas Hallgren
Joshua D. Drake wrote:
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...
Actually, I think that PL/Java versus PL/J is a good example of where
some coordination would have helped a lot.
The short story:
I was between jobs in December 2003 through February the following year.
A lot of work on PL/Java was made during that time. I had no clue that
there was another active project with similar objectives until after my
first fully functional submission to gborg. Had I known, the outcome
would have been different. Today there are ongoing and very active
efforts to collaborate.
The longer story (if anyone is interested):
Before I started PL/Java I informed the community of my intentions (see
hackers thread "pljava revisited"
http://archives.postgresql.org/pgsql-hackers/2003-12/msg00310.php ). I
got a lot of feedback and good advice such as using C instead of C++,
hosting the project at gborg, etc. but nobody told me back then that
there was an active PL/J project. I found traces of that project on
sourceforge but it seemed to have been dead for over a year. At that
time there was no redirect from sourceforge.
Jan Wieck started the thread "PL/Java issues"
http://archives.postgresql.org/pgsql-hackers/2003-12/msg00819.php in
which I made 2 major posts. Nothing in that thread indicated that there
was an ongoing project and I got no reply to my posts. On January the
7th, I made my first submission to gborg.
When I, in mid February, realized that the PL/J project was indeed alive
and active, I wrote the "PL/Java - next step?"
http://archives.postgresql.org/pgsql-hackers/2004-02/msg00713.php where
I outlined possible futures for PL/Java and PL/J. The outcome of that
was that PL/J (Dave Cramer and Laszlo Hornyak) and I had an IRC meeting
where we agreed on some limited collaboration (see "Minutes from Pl/Java
-next step IRC"
http://archives.postgresql.org/pgsql-hackers/2004-03/msg00171.php ).
From that point and until a month or so ago, the active collaboration
between the projects could have been better. Some things did happen
though. Laszlo asked me to publish some PL/Java interfaces in a public
maven repository which I did and we had some discussions. I made an
attempt to have a major sponsor step in and take the lead in a project
aiming to provide a flexible solution where a choice of approach could
be made but the sponsor understandably wanted to wait and see.
Today, we (the PL/Java and PL/J project members) make common efforts to
factor out client tools that indeed can be common to a separate project.
We are also discussing how to make the PostgreSQL user experience as
similar as possible and thus allowing use of PL/Java or PL/J without
changing anything but configuration.
Kind regards,
Thomas Hallgren
On K, 2005-04-27 at 22:21 -0700, Joshua D. Drake wrote:
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.
The big issue is communication. Because the
PostgreSQL code base is common for most of the companies involved, there
has to be coordination in what they are working on and their approaches.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.
is happening. I realize this is hard for companies because their
efforts are in some ways part of their profitability.That is true, there are sometimes strategic reasons to not annouce a
project.
I can see no strategic advantages for sponsors in not announcing the
project. There may be some small tactical wins for the actual
implementors, but not even tactical wins the sponsors.
There may be some strategic/tactical reasons for sponsors to announce
who they (the sponsors) are, but I can't see any reason not to announce
the project or not to encourage/ask/demand the implementor to do so.
profitability require duplication of effort and code collisions? I am
not sure, but if it does, we are in trouble. I am not sure the
community has the resources to resolve that many collisions.Which is why you are starting to see forks such as Bizgres but it is
also why you are seeing forks go away (Mammoth PostgreSQL).
At first glance at least, BizGres looks like a community oriented
project and I hope that BizGres will be a testbed/early implementation
of some DataWarehouse features, which will be integrated back to
postgres at first possibility.
But I too expected the discussion to take place on pgsql-hackers, not
some half-hidden mailinglist on pgfoundry. Or at least an announcement
of that mailinglist to be made on pgsql-hachers.
OTOH, there are some things (2PC, recursive queries, ...) which are
discussed on psql-hacker and still are lingering somewhere and are for
various reasons (one of them may be lack of time/money/sponsor-pressure
for the developer) not in the postgres proper yet.
OTOOH, I see that a growing number of companies who might think of
sponsoring PG development are interested in BI/DW and OLAP features in
addition to plain OLTP enchancements.
--
Hannu Krosing <hannu@skype.net>
Hannu Krosing wrote:
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.
Yes, you can bet that will happen. You can also bet that the community
release will have 2X more feature additions than any commercial release
that is a version behind unless _huge_ sums of money are thrown at the
commercial release.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Thursday 28 April 2005 01:48, Joshua D. Drake wrote:
Do companies want to write for Blue Hat PostgreSQL and Suza PostgreSQL
because that might be what happens if we don't stay organized? In fact,
it might have be happening already.Well that depends... If the companies are writing for Pervasive
PostgreSQL I don't think they would have a problem with that ;).And I do agree with you Bruce, it is happening already -- I don't think
there is any question in that.
ISTM the allure of differentiation and branding is going to be too strong for
us to prevent such things. An easy way to differentiate is to add some
proprietary/unique extension to the main code and then package that up. If
you have to have all your extensions be put into the community version then
lose this advantage over your comptetitors. (Mammoth PostgreSQL/Replicator is
an example of this) The same holds true for branding.... if your Pervasive
you want to sell Pervasive Postgres rather than PostgreSQL because you get to
push your name out there, and get people thinking about your company whenever
they talk about the database.
I think our goal is to encorage companies to push these changes into the core
as much as possible, pointing out things like the advantages community
support brings like ongoing maintainance, support in add-on tools like
pgadmin or phppgadmin, and eliminating the chance that someone else will
submit a similar solution that gets accepted to the community code there by
deprecating the work they have already done.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
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
Import Notes
Resolved by subject fallback
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
Import Notes
Resolved by subject fallback
Hannu,
But I too expected the discussion to take place on pgsql-hackers, not
some half-hidden mailinglist on pgfoundry. Or at least an announcement
of that mailinglist to be made on pgsql-hachers.
Yeah, we should announce the mailing list. Actually, I did direct e-mail a
bunch of people (including you) about it and invite them to the mailing list.
So: http://pgfoundry.org/mail/?group_id=1000107
For discussing potential features, though, I'm personally reluctant at this
point to discuss major features until I and my collaborators (example,
newsysviews) have a concrete proposal together. It's far too easy to get
sidetracked into a discussion of minutia and politics on -hackers; by
generating a complete draft spec (at least) on a small mailing list, it's a
lot easier to focus on specific goals and schedules, and discussions on
hackers around detailed proposals tend to be a lot more focused.
--
Josh Berkus
Aglio Database Solutions
San Francisco
Robert Treat wrote:
ISTM the allure of differentiation and branding is going to be too strong for
us to prevent such things. An easy way to differentiate is to add some
proprietary/unique extension to the main code and then package that up. If
you have to have all your extensions be put into the community version then
lose this advantage over your comptetitors. (Mammoth PostgreSQL/Replicator is
an example of this) The same holds true for branding.... if your Pervasive
you want to sell Pervasive Postgres rather than PostgreSQL because you get to
push your name out there, and get people thinking about your company whenever
they talk about the database.I think our goal is to encorage companies to push these changes into the core
as much as possible, pointing out things like the advantages community
support brings like ongoing maintainance, support in add-on tools like
pgadmin or phppgadmin, and eliminating the chance that someone else will
submit a similar solution that gets accepted to the community code there by
deprecating the work they have already done.
I remember something the president of Great Bridge told me, he said,
"Great Bridge needs PostgreSQL. If Great Bridge dies, PostgreSQL goes
on (as it did), but if PostgreSQL dies, Great Bridge is dead too".
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On N, 2005-04-28 at 20:13 -0700, Josh Berkus wrote:
Hannu,
But I too expected the discussion to take place on pgsql-hackers, not
some half-hidden mailinglist on pgfoundry. Or at least an announcement
of that mailinglist to be made on pgsql-hachers.Yeah, we should announce the mailing list. Actually, I did direct e-mail a
bunch of people (including you) about it and invite them to the mailing list.
Probably this got lost somewhere on the way.
For discussing potential features, though, I'm personally reluctant at this
point to discuss major features until I and my collaborators (example,
newsysviews) have a concrete proposal together. It's far too easy to get
sidetracked into a discussion of minutia and politics on -hackers; by
generating a complete draft spec (at least) on a small mailing list, it's a
lot easier to focus on specific goals and schedules, and discussions on
hackers around detailed proposals tend to be a lot more focused.
Maybe :) , still not convinced though. There may be some quite
fundamental things we may miss but which could be spotted by wider
audience early on.
--
Hannu Krosing <hannu@skype.net>
I've deliberately let the dust settle slightly on this.
One thing that might help is a more open sponsorship "clearing house".
Example (not meant as a bid, but just to illustrate): the JDBC driver
needs a scanner overhaul - it breaks on dollar quoting and a bunch of
other stuff. I could do that work (as could others, of course) but I
don't have time, unless someone buys some of my professional time.
Someone might want to do just that, but how would they find me?
Regarding the secret code stuff - I predict that it will quickly bite
whoever does it, unless they are extremely lucky.
cheers
andrew
Bruce Momjian wrote:
Show quoted text
I am very excited to see companies involved in PostgreSQL development.
It gives us funding for developers and features that is new for us. We
had Fujitsu funding some features for 8.0 and that really helped us.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. The big issue is communication. Because the
PostgreSQL code base is common for most of the companies involved, there
has to be coordination in what they are working on and their approaches.If that doesn't happen, two companies will work on the same feature, and
only one can be added, or a complex process of merging the two patches
into one patch has to happen --- again duplicated effort. I am willing
to do the coordination, or even better, have the companies involved
publicly post their efforts so all the other companies can know what
is happening. I realize this is hard for companies because their
efforts are in some ways part of their profitability. Does
profitability require duplication of effort and code collisions? I am
not sure, but if it does, we are in trouble. I am not sure the
community has the resources to resolve that many collisions.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.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 hate to be discouraging here, but I am trying to communicate what we
have learned over the past few years to help companies be effective in
working with open source communities. I am available to talk to any
company that wants further details.
Andrew Dunstan wrote:
I've deliberately let the dust settle slightly on this.
One thing that might help is a more open sponsorship "clearing house".
Example (not meant as a bid, but just to illustrate): the JDBC driver
needs a scanner overhaul - it breaks on dollar quoting and a bunch of
other stuff. I could do that work (as could others, of course) but I
don't have time, unless someone buys some of my professional time.
Someone might want to do just that, but how would they find me?Regarding the secret code stuff - I predict that it will quickly bite
whoever does it, unless they are extremely lucky.
Let me add that we really do want these companies to succeed.
For me, it is all a matter of meeting the company's expectations. If a
company wants to add a closed-source feature to PostgreSQL, that's fine,
but if they work on a features and eventually want it integrated into
the main code, I don't want that to fail and have them be disappointed.
The same goes for duplicated effort --- if they don't wnat it to happen,
I want to help them prevent it.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Andrew Dunstan <andrew@dunslane.net> writes:
Regarding the secret code stuff - I predict that it will quickly bite
whoever does it, unless they are extremely lucky.
Yeah. Bruce and I were worrying about this on the phone today.
If a company is doing some work with the intent that it's a proprietary
extension they can sell, no problem --- the BSD license is specifically
intended to let them do that. What's bothering us is the thought that
people are off in corners developing code that they think they are going
to contribute back into the community code base "after it's done". Past
history shows that the odds of getting such things accepted into the PG
community code base are *very* bad if you didn't communicate with the
community from the start of your development process.
We'd like to avoid such unpleasant surprises, but how to get the word
out?
regards, tom lane
On Fri, 29 Apr 2005, Andrew Dunstan wrote:
One thing that might help is a more open sponsorship "clearing house".
Example (not meant as a bid, but just to illustrate): the JDBC driver
needs a scanner overhaul - it breaks on dollar quoting and a bunch of
other stuff. I could do that work (as could others, of course) but I
don't have time, unless someone buys some of my professional time.
Someone might want to do just that, but how would they find me?
I don't think this is a big issue. I don't know of any companies who were
desperate for a feature and willing to throw money at the problem who
couldn't find a developer to take them up on it. Right now this seems to
be a kind of behind the scenes operation that relies heavily on knowing
the right people, but I think most of our sponsor contact points are able
to point sponsors to the right people. Could this process be more open?
Depends on how the sponsor wants to handle it, they probably don't just
want to throw the task out there and see who comes calling, they want an
assurance from someone they trust that the chosen developer is capable.
One thing that definitely would be nice would be to be able to combine
funds from various sponsors for various features. Alone a company can't
spring for it, but by pooling resources it could get done. This is a lot
tougher to coordinate and unless there is a complete spec in place
different sponsors will pull in different directions. Other bounty type
schemes don't seem to produce results, largely from a lack of cash.
(Here's $500 for two weeks of work).
Anyone care to shed some light on how it works now?
Kris Jurka
