Re: Patch committers

The following email expresses my personal opinion and does not reflect
the opinion of my employers.

Bruce Momjian wrote:
> I also think the bad economy is making it harder for people/companies to
> devote time to community stuff when paid work is available.
>
Actually the bad economy should be a booster for open source projects.
There should be more developers with time to acquire new skills on
projects that will get them a better job when the economy comes back.

I think the problems are more rooted in the developer community itself.
The pg-hackers mailing list is probably the less socially skilled
developer community I have ever seen in all the open source projects I
have been involved with. A very high standard is set for contributions,
which is good for the quality of the code, but the lack of development
process and clear decision chain turns every new contributor into
endless frustration. For a patch to be committed, a vague consensus has
to arise among the strong technical voice(s) (usually convincing Tom is
enough). If a more complex feature needs to be implemented, the lack of
decision process ends up in a first long round of emails until everybody
gets tired of it. Then sometimes later someone tries to re-activate the
debate for another round and so on (partitioning is a good example). You
lost potential committers at each of these rounds.

The way I see it, most companies try to push their agenda, contribute
their patches back to the community if it works and just go with their
own fork and closed implementation if this is too much work or burden.
Whatever the economy, very few people can commit to an indefinite amount
of time to get a feature integrated in Postgres.

Now you should probably ask yourself what you should do as a community
to get more committers? Like it was said at PGCon, to get a patch in, it
is going to be hard and painful. How do you make it less hard and less
painful?

On the other end, how do we, simple developers, become better to reach
the status of committers? How can we endure the constant bashing
especially in the early stages of our learning phase (especially if you
are not paid to do it)? How do we justify to our employers that they
should persist through this long process without visibility, so that
eventually their contribution will make it back to the community? How do
we make it easier for companies to contribute code?

The lightness of the development process (no project manager, no
steering committee, no voting, no product management, ...) is both a
strength and a weakness that makes Postgres what it is today. The
commitfest started to address some of the most obvious issues but there
is probably much more that can be done by looking at what is happening
in the other open source communities.

Even if the economy is hard, I found time to invest my own 2 cents in
this email ;-)

Emmanuel