[OSGeo-Conf] Need to define rules for %age of backflow of FOSS4G surplus

Steven Feldman shfeldman at gmail.com
Tue Jan 7 02:33:32 PST 2020


Perhaps we could consider a different approach for the European and North American events to the “Other Regions” particularly where the host country or region needs support to grow the local community (of course there could also be a case for growing a local community in NA or Europe).

l think the challenge that we face is that we already have a lower expectation of surpluses from the event in “Other Regions”, if we now leave a larger share of the surplus in the region we will return very little to OSGeo in one of the 3 years of the FOSS4G cycle. I don’t know what proportion of OSGeo’s income comes from FOSS4G so I cannot guage the impact of reduced surpluses from FOSS4G. That may be a risk that the board is willing to accept, it is not for Conference Committee to decide. Till could you raise this topic with the board and provide some guidance to CC
______
Steven

Unusual maps in strange places -  mappery.org <http://mappery.org/>

Subscribe to my weekly “Maps in the Wild <http://eepurl.com/dKStT-/>” newsletter

> On 7 Jan 2020, at 10:00, María Arias de Reyna <delawen at gmail.com> wrote:
> 
> I'm trying to avoid jumping in this thread as I am a very interested party here. I don't want to influence much the general rules for future events based on what we need right now.
> 
> But consider this:
> 
> I'm in favor of "capping out" the total to the local chapter.  Unless
> a local chapter has a particular method for spending the funds in some
> useful way, I don't think that more than $10-30k is useful. 
> 
> Having the funds in advance to be able to organize a regional and local event without having to worry when then money is going to be available on the bank account is a huge relief and helps a lot on the sustainability of the regional events. Maybe the question here is if we want a centralized OSGeo fund system or we rely on the local/regional chapters to be able to handle funds. Both options have advantages and disadvantages. 
> 
> Yes, probably a profit of 200k is too much for a regional/local chapter.  And maybe 30k looks like a lot if you are thinking on organizing small events. But for example, when it comes to a regional event that wants to also have a TGP, that money in advance is key to be able to do it properly. Even when you are sure you will have profit, tickets and sponsors are incomings that can came too late.
> 
> And I know what you are going to tell me: we can ask for money anytime so OSGeo gives us seed money or donations when needed, we don't need to store it ourselves. But right now I'm thinking on my particular case, where each transfer to/from Argentina is painful due to currency exchange. Giving money back to OSGeo in 2021 to ask again for money later means losing money on each conversion. Painful. And my "poor person" mindset quickly jumps into "better leave the money sitting here, we have time to give it back to OSGeo later if needed".
> 
> IMHO we should prioritize empowering regional and local events and leaving "traces" of the OSGeo budget on different places can help a lot here. I bet Argentina is not the only case where fees or currency exchanges or similar "eats" a portion of the cake. Maybe others just assumed it as normal and didn't consider they can store part of that money instead of paying extra fees? The important thing is to use the money to keep OSGeo running. If it is centralized or not... I don't know that is best.
> 
> TL;DR: Each chapter will have its own reasons to ask for a different profit percentage. Guidelines are good, but write them in stone may discourage some locations.
> 
> And I disappear again. 
> 
> Cheers!
> María.
> _______________________________________________
> Conference_dev mailing list
> Conference_dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/conference_dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/conference_dev/attachments/20200107/9d697a64/attachment.html>


More information about the Conference_dev mailing list