Re: On what we want to support: travel?

Andrew,

> Which is why asked the question, do we want to be in the business of
> subsidising travel. Others seem to think that the answer to that is
> obvious. But "travel" covers a lot of ground, and it seems to me
> that we ought to have some set of ideas of what we're likely to fund
> and what not, so that we don't have to waste a great deal of time
> evaluating requests that we were never going to fund anyway.

+1

> Here are categories of travel, for instance, that I think might be
> good to support:
>
> - Invited talks to conferences in areas of current growth
>
> So, e.g. talks to PHP conferences, SIGs for communications
> and industrial developers, and geographic areas where we seem
> to have some traction.
>
> - Developer travel to feature-development sessions
>
> I'm told that some people find it better and faster to get in
> a room together and work out how a feature should be
> implemented (particularly big, complicated ones). Meetings
> for that sort of thing.
>
> - Industry/standards bodies meetings
>
> I dunno about TPC or ANSI, but I'll tell you that IETF
> meetings are actually productive, in my experience. It isn't
> especially what is decided in formal sessions, so much as the
> thrashing out of nascent proposals in the hallway, that make
> it worthwhile. I suppose this is related to what's above.
>
> But, for instance, I _don't_ think we should fund travel for
> "regular" conference talks, or sending people to places where we have
> a well-established presence like OSCON.

I agree with all of this.

There needs to be one more evaluation point as well: how likely is one of our
corporate supporters to pay for each item with out general SPI funding? For
example, for as long at I'm at Sun, PostgreSQL does not need a TPC
membership ... Sun has one (and, frankly, I wouldn't want to send a random
community member to TPC anyway, it's *highly* political and only secondarily
technical). And for developer meetings, this year both EnterpriseDB and
Greenplum have paid for some, so if we needed a community-funded one it would
be for the clustering folks only.

> One thing about ROI analysis that does not translate well from
> industry to open projects like this is the "return" part. It isn't
> plain _at all_ what the return in a project like this should be. For
> a company, it is plain: expected financial reward. Since everything
> in a firm's ROI calculation is measured in money, the comparison is
> relatively easy. But because we haven't monetised the community, we
> can't compare everything in terms of money. Therefore, we need to
> think not only in terms of ROI, but also in terms of general goals of
> the community. That's what I'm trying to learn through this thread.

Well, there's a couple of "returns" in my mind: (a) the quantity and quality
of additional community members we can gain, and (b) what it adds to making
PostgreSQL a better ("more advanced") database.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco