On Fri, May 13, 2016 at 12:35 PM, Joshua D. Drake <j...@commandprompt.com> wrote: > Hey, if I am wrong that's awesome. The impression I have is the general > workflow is this: > > * Company(1) discusses feature with community > * Company(1) works on patch/feature for a period of time > * Company(1) delivers patch to community > * Standard operation continues (patch review, discussion, etc..) > > This is not "bad" but it isn't as productive as something like this would > be: > > * Company(1) + Company(2) get together and discuss using their > respective resources to collaboratively develop X (multi-master for > example). > > * Company(1) + Company(2) discuss feature with community > * Company(1) + Company(2) work on patch/feature in the open, > together > * Company(1) + Company(2) deliver patch to community > * Standard operation continues (patch review, discussion, etc...) > > The difference being one of coopetition versions competition for the > betterment of the community. If there are companies that are doing that > already, that is awesome and I applaud it. I was just trying to further > drive that idea home.
I think that's already happening. I'm happy to see more of it. In practical terms, though, it's harder to collaborate between companies because then you need two management teams to be on-board with it, and there can be other competing priorities. If either company needs to pull staff of a project because of some competing priority (say, fixing a broken customer or addressing an urgent customer need), then the whole project can stall. The whole wagon train moves at the pace of the slowest camel. It's nice when we can collaborate across companies and I'm all for it, but sometimes it's faster to for a single company to just assign a couple of people to a project and tell them to go do it. Now, where this gets tricky is when it comes down to whether the end-product of that effort is something the community wants. We all need to be careful not to make our corporate priorities into community priorities. Features shouldn't get committed without a consensus that they are both useful and well-implemented, and prior discussion is a good way to achieve that. On the whole, I think we've done reasonably well in this area. There is often disagreement but in the end I think usually end up in a place that is good for PostgreSQL. Hopefully that will continue. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
