A week or so ago my old friend and colleague Clint Lalonde posted his annual update on “Supporting What He Uses,” his annual effort to support financially some of the free and open sites and tools he benefits from. It’s something I thoroughly support and have done for years, with annual donations to Wikimedia, Creative Commons, Open Media and the like.
In the comments on his post I mentioned a policy I helped put in place at the BC Libraries Co-op, where I work, that is similar. But I also realized I was remiss in not writing this up further at the time it was created, probably because at the time my old site was in a state of total disarray. So here’s my belated attempt to do so now.
The Co-op where I work uses as close to 100% open source software as we conceivably can. It was a huge attraction for me in coming to work for the Co-op. Our flagship offering, Sitka, is based on the Evergreen open source ILS. As a company, we contribute back to this in many ways: through regular code contributions; adding to documentation; by having staff serve on the board; by contributing to the Software Freedom Conservancy. We are I believe a model of a good partner and actor in this community, giving as much as we take.
But we rely on MANY other open source projects throughout our enterprise. We run Ubuntu everywhere. Our Libpress service depends on WordPress, the Library Toolshed and NNELS sites on Drupal. We run Postgres and MySQL, ceph for enterprise storage, and way too many smaller pieces to keep the servers humming. And while we always strive to be good open source citizens, truth be told on many of these we’re just users, not giving anything back.
Which is fine…there’s nothing saying you have to. Except, when you depend on all of these pieces, you realize you are part of a larger ecosystem, some of which are not as well resourced as others. Nowhere did this become so apparent as with the infamous Heartbleed vulnerability. Up to a 1/5th of websites globally were potentially affected, and yet it was later revealed that this essential piece of security technology was being maintained off the side of their desks by a couple of developers. Ultimately a number of major firms stepped up to better resource support for OpenSSL, but it was this very vulnerability that drove home the point that we are only as strong as the ecosystem we participate in, and that as a social enterprise, the Co-op needed to think of additional ways to contribute back.
Thus began the development of our Open Source Contribution Policy. This policy (which I don’t think we stuck a CC license on, but know we’d be happy if you copied) sets aside an annual fund, dispensed at the discretion of the ED, for “the explicit purpose of contributing to the betterment of Free and Open Source Software and its surrounding ecosystem.” This contribution can take many different forms, some of which might be:
- Donations directly to specific projects, for example http://donate.perlfoundation.org/index.pl?node=Contribution%20Info
- Donations to foundations or other umbrella organizations which aggregate and redistribute resources across multiple FOSS projects and initiatives. Examples are https://osuosl.org/donate, https://www.owasp.org/index.php/Donate or https://www.apache.org/foundation/contributing.html
- Sponsorship of bug bounties to help fix or improve specific software functionality, through sites such as https://www.bountysource.com/
- Purchasing of support contracts from entities that have an established track record of code contributions to the project they support. An examples is http://www.ubuntu.com/management
- Hire a Coop Student to improve documentation or create an alternative theme or extension on a product which is important to the Co-op or our members, for instance https://www.dokuwiki.org/
In addition, the policy sets out criteria by which we can assess which projects to direct funds to:
- Is it FOSS actively in use at the Co-op?
- Can the project or organization meaningfully accept and use the donation?
- Is the project receiving funding stable and mature enough that it will continue in the immediately foreseeable future?
- Does the project or organization have fiscal need? Does the project or organization have a commercial arm or business model that already serves to sustain it?
So far we’ve had 1 year of running this fund. Last year, after consulting with staff, we directed funds to: the Drupal Association (in the form of a membership); the Horde project (which we use as our primary webmail client) and the Apache Foundation (of which we use numerous programs.) We just had our annual All Staff meetings where I got the chance to ask staff again for feedback on which projects we can contribute to, and as we approach year end hopefully we’ll be able to do so again.
Ultimately our fund is a tiny drop in the bucket. I feel really good about it as an organization, but my larger goal was to set an example for other organizations who similarly benefit greatly from open source software and yet maybe don’t always give a lot back. In this regards I’m thinking very much of many post-secondary institutions, whose server rooms are often chock-a-block with FOSS. Ideally I’d love it if they realized that one of the main freedoms of FOSS, the freedom to learn from your software, aligns incredibly well with their mission as institutions, and so their contributions should be in the form of direct engagement and improvement. But failing that, maybe they can at least consider how to take a tiny portion of their large IT budgets and help make the larger FOSS ecosystem stronger. – SWL
