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(a)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
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil