This is something that I have had a number of discussions on recently, including with several clients, and also with Simon Riggs of 2ndQuadrant at PostgresOpen. Sometimes, especially with larger development items, it is quite difficult to estimate the amount of effort required to undertake a certain item without actually doing a quite substantial amount of work to start with. I am often very conservative in giving estimates, and won't do so unless I feel reasonably confident that I can hit the target in the specified time. This is to protect myself, PostgreSQL Experts Inc., and the clients. In at least one case recently a client decided not to pursue a certain item because I would not put a firm estimate on it without this initial investigation.
A case in point is the Grouping Sets feature (CUBE and ROLLUP are instances of this feature). It's one I would like to land. Some work has been done on it a few years ago, but clearly a lot needs to be done, and I have no idea how much. Finding out would probably cost me a lot of time and effort, which I can't afford to undertake unfunded.
Some people get this, I'm happy to say. Yesterday we reached agreement in principle with a client on proceeding this way for a feature that I hope will eventually land in Postgres (details will have to wait, I'm afraid). Without this approach we would almost certainly have declined the work, and the feature might never have seen the light of day. I hope other people wanting to sponsor developments can see the point of this.
It is still early stages for the system, yes. It is intended to be a weekly stipend from those willing to contribute to specific hackers, however. It's not a one-time only gift. I think as more people decide to fund developers they know contribute to the development of major features for their software of choice, you might be able to ask less from corporate sponsorship.
There's a much bigger problem with commercially-funded developments in a decentralized project such as PostgreSQL. You can't guarantee that your patch will be committed. <br />
For now, most of the "funded features" that I know of have been committed because they are long-awaited and uncontested, like Gin Index for example. But what if a client is asking for a more disputed patch, like cloning the SHOW command from MySQL or implementing query hints ? In such case you can't be sure that your code will be accepted by the community. And the only way to know is to develop and submit the patch. So what happens if the patch is rejected ? Do you refund your client or is he paying anyway ? <br />
There are even more tricky situations. For example let's say that the patch was accepted. But during the review process another community member (like say, Tom Lane) rewrote half of your code to make it work correctly with the rest of the codebase. Do you give half of your client's money to him ?<br />
Selling developments without controlling the commit process seems like a risky business to me. Did i miss something ?
To take your last point, the answer is no. Example: I was funded to do parallel pg_restore. I put in literally weeks of work on it. Tom did in fact rejig some of what I did. Did I give him any of the funding money? No, nor do I feel the least bit guilty about that.<br />
Features that are contentious need community buyin before you start coding. That's the basis I proceed on, and I imagine other people do too. Anybody who doesn't deserves all the grief they might get. That's true regardless of funding.<br />
As for what happens if the patch isn't accepted, that depends on the terms of the funding contract. I usually have a pretty good relationship with my funders, so it's never been a problem for me.
I didn't say you should feel guilty or anything. Sorry if my previous message seemed a bit harsh.<br />
I'm know you're doing a great job and I'm sure these kinds of funding work fine for you. What I tried to point out is that it may work a handful of PostgreSQL long-time core-hackers but it doesn't scale the larger developer base.
Corporate funders of open source development should know that they can't control the commit process. In the end a decision about whether or not something goes in is a community decision. Even I as a committer cannot guarantee that something I develop for some funder will be committed. If that's a deterrent then they probably shouldn't be in this game to start with. Luckily, there are people who are prepared to fund developments without such guarantees.<br />
Does that scale? I don't see any reason it shouldn't. Yes it possibly helps if you hire a long time contributor to do the work, because such people know how to negotiate the process smoothly. But it's not like there is some closed cabal. In at least one case I have been called on to advise people how best to get their work accepted, rather than doing the work myself. Getting hold of someone in the community to help you like that is a good move for corporate organizations new to the Postgres world. It spreads the load and helps grow new Postgres community members.