Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, May 13, 2016 at 12:35 PM, Joshua D. Drake <jd(at)commandprompt(dot)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