At least about non-profit software organizations that we rely on (aka upstream projects), I agree with the idea of having a strategy of support and the sensible resources to support it.
The easy part is to explain the principle and the strategy to our editors and donors. We got here because these projects were also here to support us. If they fail, we will suffer.
What is more complex is to have a software strategy mapping our current and future needs to our own development resources and to the upstream projects expected to provide the rest. Some upstream projects will do well with or without us, while others will rely more heavily on us. Different projects will have different needs at different points of time.
Being a supporter in the free software community is not very different to being an editor in Wikipedia. Good contributors don't focus in just giving money, just like good editors don't focus in just adding text. Our help is more useful when we contribute with our various interests and tools, filling different types of gaps that others have left.
On Tuesday, April 15, 2014, Erik Moeller erik@wikimedia.org wrote:
I could imagine a process with a fixed "giving back" annual budget and a community nominations/review workflow. It'd be work to create and I don't want to commit to that yet, but I would be interested to hear opinions.
Planned budget and community process are important elements in this equation, but a broader strategy would need to be in place first. In my opinion, such strategy would focus mainly on long term relationships based on actual exchanges and collaboration before money gets into the picture. Leaving a % of the budget for opportunistic support to non-planned actions is very good, but only when the basic collaborations are in place. Otherwise we risk to run into the known problem of supporting many activities and many organizations at a remarkable cost, without seeing clear benefits after a couple of exercises.
I would also start using and contributing improvements to the tools and processes we currently have, like the family of Grants tools, rather than creating new ones for this purpose.
Just like featured articles start with a single sentence, we could also start with a very simple iteration, already in the 2014-15 plan, keeping what we have done (e.g. the Freenode collaboration) and adding a bit more. The same goes for the software strategy, we don't need to have a 5-year plan to start nailing down some obvious conclusions that will help us nominate a first list of partners to support formally.
In fact this is one of the reasons why the Engineering Community team has the short term goal of documenting an accurate list of upstream projects:
[2] Cf. https://www.mediawiki.org/wiki/Upstream_projects