[OpenLayers-Dev] Entering OSGeo Project Sponsorship

[Christopher Schmidt]

On Fri, Oct 17, 2008 at 02:32:39AM -0400, Erik Uzureau wrote:
> solid +1 from me on all this, chris.
> 
> my only thoughts at this point are:
> 
> 1) management/infrastructure: what are the actual logisitics for getting
> this money, dividing it up, allocating it? i would assume that osgeo has the
> apparatus in place for the first part (taking it in, taking their 25%) but
> then after that, how do we roll? are there any wierd tax issues with this?
> will OpenLayers be making contributions to political parties?

OSGeo will handle invoicing sponsors, taking in the the money, and
holding it. Since OSGeo is working on becoming a 501(c)3 organization, I
believe that direct contributions to political campaigns would be
against US Tax Law. :) (So if we hurry before OSGeo gains that status,
we can go ahead and give all our money to Mickey Mouse's Campaign.)

As far as spending money, the project sponsorship wiki page says it is
the project's responsibility to:

 * Pass well documented motions for any expenditure of funds from the
   project sponsorship fund.
 * Provide clear direction (via the project chair/VP) to the OSGeo
   Treasurer for any payments to be made from the project sponsorship fund.

 -- http://wiki.osgeo.org/wiki/Project_Sponsorship#Project_Reponsibilities

So, the PSC makes a decision, and then we make it very clear as to what
is supposed to happen to the OSGeo treasurer, and that person makes it
happen.

> 2) having a "budget", even if it's not huge, I think adds a whole new
> dimension to the responsibilities of the PSC. if this is something we want
> to pursue seriously, i think it would be worth:
> 
>      2a) drawing up some formal guidelines for how this money is to be
> spent: ie. votes by psc on propositions, etc

It is my belief that we should intentionally not pursue this unless we
see evidence that sponsors are balking at the idea of not having such a
thing put together. The entire point of the sponsorship support is to
put together funds that the PSC can use *at its discretion* -- which
means that setting up a formal list of guidelines constrains us from
doing.

The sponsorship document provides information to sponsors as to what the
PSC expects to spend money on -- and if we see other things that we
expect to spend money on, we should expand that informal list. However,
this is not a contractual agreement, and sponsors are, to some extent,
simply investing in OpenLayers and trusting the PSC to do the right
thing. 

I have seen no cases I'm aware of where the PSC has completely ignored a
request, or even, generally speaking, acted against the will of the
project, so at this time it seems likely there is a fair amount of
trust in the PSC. Fixing that, if there is not, is an important part of
the process for gaining sponsors. 

>      2b) reconsidering the current composition of the PSC: I know this
>      has been discussed on the side a bit recently, but I think your
>      comments in the below emails are spot on 

I agree that this is an appropriate move for the PSC to take, and
probably has been for the past year. There are a number of changes in
the contribution makeup of the project, and the PSC should reflect that. 

> and that companies who would like to be sponsors will want some sort
> of semi-direct way of having their opinions voiced.

Having their opinions *voiced* is easy: PSC discussions take place in
public on the developers list, and we also will need to pursue feedback
from sponsors via surveys (as stated in the sponsorship doc). The PSC
has never ignored the cries of a majority of the project.   

> whether that is a direct seat on the PSC or some sort of wierd proxy, an
> even and justified PSC is I think a prereq for going out and sellling this.

The first half of this sentence and the second half are not directly
related. A 'fair and balanced' PSC is a fine prerequisite, but 'fair and
balanced' should be related to the *project's* interests, not the
sponsors. 

I doubt that we will see many people who are interested in sponsoring,
but think there are members of the PSC (other than myself ;)) who don't
have the project's interests at heart in their actions on the PSC.
Sponsoring means that you have to trust the PSC members: If you don't,
it's not clear to me that sponsoring the project makes sense until you
do. (Building that trust may require a slow buildup of the sponsorship
program, to be sure: It's hard to build trust related to money without
having money that people trust you with.) 

> Notably, the creation of our PSC was made not on a whim but also certainly
> not in a controlled laboratory setting*.
> 
> 3) if it were up to me, any money that we could somehow bring in from
> sponsors should be directly invested in "bunker" weeks, as we have been
> having in the past. 

I disagree with this strongly. For a time, you were extremely successful
in acting as a 'maintainer' for the project: ensuring that emails were
responded to, tickets were opened, etc. At other times, I have managed
the tickets: ensuring they're put in the correct milestone,
handled/assigned to people, etc. I think this type of activity directly
supports the project in a way that is hard to quantify: it increases the
quality of *all* of our communications with our users and developers to
have a coherent vision of the problems that people are having. Simply
trolling the list regularly for questions/bugs that are encountered
frequently, and pointing these things out to developers, is something
which could help the project out -- and is hard to support on an ongoing
basis without a significant time commitment (and in the end, all time is
money, in one way or another).

> there seems no question in my mind that these have
> always been super successful and very positive social events that open up
> communications channels, turn out a bunch of code, and allow otherwise petty
> developers like myself to feel something like important businesspeople, what
> with the "gotta catch a flight", and the casual droppings of "my colleague"
> to skeptical concierges and waitresses around town.

Absolutely, but I don't think that these bunkers are the *only* way to
help the project: there are others that we have done 'for free' and paid
little attention to, but which could possibly be said to help out the
project even more.

> In the past, the way the bunkers have always worked is that we have a fixed
> number of days, and everyone sort of shows up to the bunker with their own
> agenda. Agendas can either be merged in the leadup to the event or in the
> first few hours/day... but it seems at any rate a mostly democratic way of
> doing things. When it's the case that your company is paying to send you to
> a bunker, the message is clear that you should at the very least make an
> effort to promote the ideas for projects your company would like to have
> moved forward. I imagine it would be no different with sponsors: "Well Apple
> has given us $38,000, I guess we should port OL to the iphone" or something
> of that nature.

This is exactly the type of behavior I'd like to have developers not
follow directly. That kind of sponsor-led project development is
intentionally ignoring what the *project* needs most -- and even with
$40k in the bank, we still have a lot more total investment in time and
energy by our various contributors, even if you value their time pretty
cheaply.

The key point I'm making here is that I don't think sponsorship should
be seen as a way of controlling the project. It should be a way of
helping the project to do what it wants to do anyway.  

> What I wanted to get at, though, is the difference between the bunker
> approach and the direct subcontracting approach is that, especially in the
> case where we're not talking about a big chunk of money... it is I think
> pretty easy to spend the money on common things that would effortlessly
> benefit all bunker-attending contributors -- and therefore the openlayers
> project as a whole. things like renting office space or internet
> connections. paying for lunch or even some sort of lodging subsidy. The idea
> being that if it could somehow be split evenly over all attendees, well all
> that might just simply translate to less headaches for the PSC in terms of
> taking heated decisions on who gets what, which I can see as a potential
> nastiness that at least I personally would rather avoid if possible.

Sure, but code sprints don't achieve all the needs of the project. I
agree that subcontracting for features is generally speaking a mistake,
but I'm not sure that I agree that paying people for maintenance of the
project in a number of ways is. 

> Now, this is of course is assuming that when company x expresses interest to
> sponsor us with HEAVY insinuations that this should be for "implementing the
> blah control" or whatever, that desire should most certainly be taken into
> consideration and hopefully carried out (either in bunker time, or if need
> be via direct payment consulting).

I disagree. If companies want a feature done, they should pay someone to
do it. If they want to support the PSC in whatever we want to do, they
should sponsor it.  

> it's now getting really late and I should be asleep. so if any of the above
> doesn't make sense, you'll have to forgive me. I haven't yet gone through
> and installed my MailGoggles[1] yet :-)

I think it makes sense, and actually matches what I thought the first
time I passed my mind over the idea; but as time went on, I realized
that really, direct impact on the direction of the project is not
something to be encouraged via the sponsorship program. Instead,
sponsorship should be seen as a way of helping the project to achieve
its existing goals. The somewhat limited form of sponsors direct input
into the project is an intentional side effect of this point of view,
and is based in part on GDAL/OGR's successes with the project.   

> * Most glarlingly, the fact that I happened to be the original "chair" of
> this committee seems almost pulled out of a hat, and that I remain in office
> now some 2.5 years later more a testament to social grace (or disorganized
> mutiny) than any sort of reflection of my knowledge, coding style, ideas
> about the future, or even my occasional, presumptive, 3/4-hearted attempts
> at "managing".

Actually, although the original decision was somewhat ad-hoc (as I
recall, the way it worked is everyone said "CHris should be chair!" and
I said "No Way!" :)), I could not be happier with the choice. Of all of
the current PSC members, I think that you have demonstrated the widest
ability to take an accurate barometer of the social pressures pushing
different members of the PSC and the project as a whole, and integrating
them into ideal compromise situations, something that I think that other
members of the PSC would have far more trouble achieving. (I know I
would.) 

Your tenure as PSC chair is a testament to your continued ability to
hold the project together better than anyone else could, as far as I'm
concerned, stretching from your ability to chat for hours on the phone
about the various issues related to a release, to the ability to step up
as release manager, to your consensus driven comunication style, which
has worked out perfectly for the 'chairman of the board' position that
you hold. Given my druthers, I personally wouldn't have it any other way
if I had to start all over. (Others, on the other hand, may feel
differently. :)) 

Regards,
-- 
Christopher Schmidt
MetaCarta