-
They should certainly budget to obtain service and ensure they pay the companies and people that make the software upon which they depend, whether they need support or not. If they don’t, it might not get updated again. And I like the idea of budgeting a minimum amount for this. But I’m not so sure abstract “giving to the community” is a good idea. Experience shows that a community selectively paying community members to participate demotivates everyone else.
-
Another valuable EFF action, this time protecting “safe harbour” for service providers. Robust legal protection for common-carrier-status is a vital part of enabling innovation and growth.
-
The most important aspect of this is that India requires royalty-free (and not RAND) licensing for patents in standards.
Filed under: Links |
Wild Webmink 
Agreed on the first link. Tithing is a simplistic concept, but it’s important to look at your vendors and make sure they’re not going away anytime soon – open source or proprietary. With proprietary you pay for the product as your contribution to keep them going, with open source it varies.
The Perl communities method of hiring Damian Conway to work on Perl for a year for them was an interesting one; he spent the time in design land and presenting all over the world [iiuc]. Hiring someone to code full time just messes with the volunteer ethic, the only ways I’ve seen that work itself out is to decrease the productivity (for example give them multiple projects to work on) or to have the employed and the volunteers separate the areas of work.
Providing cash is sometimes good, but many projects aren’t ready to take cash and even more don’t know what to spend it on.
Funding more specific tasks can be better for the project – organizing a foocamp, paying travel budgets, infrastructure. My suspicion is that that becomes more painful for the company offering the money, tax etc.
A subset of the various of the above would be specific roles. Paying someone to do something that isn’t usually well handled by volunteers. Improving the level of QA or making design improvements. That wouldn’t conflict with the volunteers, and it’s likely you could make part of their job making it easier for those like them to volunteer.
It’s not the case that my time working for the Perl community was exclusively devoted to design and outreach. As part of my grant I also created 14 new software modules, several of which were added to the Perl core distribution. I also made significant upgrades to 7 existing modules. See http://www.perlfoundation.org/2001_development_grant_to_dr_damian_conway for details.
Of course, the outcomes of this particular grant represent only a single data point, and an unusual situation as well, so I don’t feel we can draw useful inferences from it (either way) regarding the general success of paying for Open Source development.
One of the defining characteristics of Open Source software is that is is “non-rivalrous”. So most support for Open Source development probably should be too. Unfortunately, that generally means that such development must be paid for in non-rivalrous currencies (reputation, kudos, respect, free hosting, community discounts on books or conferences, etc.), or must be restricted to individuals in unique positions within a community (such as the progenitors or leaders or specific projects).
However, I do think there are several cash-based corporate “payback” models that work well. Organizations can directly or indirectly support Open Source development by funding the leaders of Open Source communities to work for their communities (as O’Reilly did for Larry Wall for many years, and as Google sort of does today for people like Guido von Rossum and Bram Moolenaar); by buying supported Open Source software from companies like Canonical, Red Hat, or ActiveState (who, in turn, employ many Open Source developers); by hiring individual developers or Open Source development companies to solve particular problems in a specific distribution (and, of course, allowing them to fold the patches back into the public distribution); or supporting Open Source developers like myself by buying our other services (training, books, consultancy, etc.).