A Modest Proposal: A Structured Tax-Exempt Structure for Corporate OSS Development

Today's columnist is Carlo Daffara from Conecta. He writes:

One of the most common observations in the open source marketplace is related to the low level of contributions by companies, especially small and medium sized businesses, to the projects behind the open source software (OSS) they use within their embedded systems or as part of an internal IT infrastructure. Looking at the Eclipse Foundation, one of the best run open source projects, it is possible to see that most contributions are from large companies that use Eclipse as a basis for their products or from open source companies that are aware of the strategic importance for code contributions to OSS projects.

What is missing is the large number of companies that may be interested in contributing and who perhaps are already sponsoring some internal developer's work on the project. However, they are not able to structure their contributions in a formal way. The reason is threefold: knowledge, legal, and economics.

Knowledge: most companies are unaware of the fact that they can contribute back or do not know how to do so. Maybe an internal developer is able to submit patches, but the company itself does not understand how to fully engage with the open source project. For this reason, many contributions are from individuals using a company email. Company managers are often unaware of the use of OSS inside of their own products or infrastructure, and do not understand what advantage may be obtained by giving back to the project. In fact, most companies are limited in the first step of the OSS adoption ladder identified by Carbone and moving up the ladder from "use" to "contribute" is a much rarer step.

Legal: companies are often wary of backfire from an "official" contribution. They fear that internal intellectual property (IP) may be revealed. Some licenses provide implicit patent granting, which may limit the ability of a company to ask for licensing fees later. Some companies avoid this scenario accurately; for example, some of the contributions to OSS by Microsoft were developed by external companies that held no IP under contract from Microsoft, and were released in an indirect way.

Economics: why should a company contribute? What economic benefit can it bring? Unless there is a clear business advantage, most companies will not face the risks and costs of contributing code, and prefer taking the "developer did it" approach.

I would like to propose a blue-sky experiment: a clearinghouse for code contributions. It can be imagined as a traditional software development company, but under non-profit and tax-exempt status. This would be similar to the Mozilla Foundation, but would aggregate development activities from many different companies and covering a wide spectrum of projects. The clearinghouse can accept tax-exempt donations, clearly marked towards a development objective, and visible through a project dashboard, such as the one used by the Eclipse project. The clearinghouse can then parcel the work out with a bounty system, if the work is small, or directly by paying the developers of the original project for the activity. This way, the OSS project can receive an immediate benefit.

The biggest difference between current structures would be the:

• coverage of a large number of projects, increasing the sustainability of the clearinghouse itself


• legal coverage, as the development would be done by a third party, not impacting any potential IP held


• efficiency of the structure, reducing the ramp-up effort for internal developers to become proficient with the source code itself


• tax-exempt status of the donation, providing an economic benefit on top of the increased efficiency of open source development

Such a structure can be made in a relatively simple and cost-efficient way, one per continent to simplify the legal process. In my opinion, this can be a first step towards increased participation by those companies that now use open source, and still are unaware of the potential impact of contributing. We tend to overestimate the impact of large contributions and forget that, for example, in the Linux kernel 25% of the change sets are from unaffiliated developers, the single largest group. If we can turn at least a small part of that 25% into paid services under a tax-exempt umbrella, we radically increase the economic market for open source services.

Facilitating Non-Code Contributions

In today's column, Carlo Daffara continues his discussion on non-code contributions:

In a previous column, I mentioned how a substantial amount of contributions in large projects are not provided in the form of code, but in many other forms. Examples include documentation, knowledge (maybe enclosed in mailing list posts), graphics, and so on. Code is actually one of the last, and most complex, form of contribution as it does require substantial skill and knowledge. While it is true that most projects provide a structured form to submit and contribute code, there are very few projects that make it easy to submit other types of contributions.

A good start is to show that you actually want contributions. There are countless open source projects that never mention in their web page or documentation the fact that external participation is welcome. Having a page like “contribute” on your project website is a good start. A perfect example is the Fedora Project page.

In this example, the join page is really a contribute page and is found just after the link on how to obtain the distribution – a very visible and clear position. The page also shows the many different ways someone can contribute: by writing text or documentation, contributing graphical elements, by being an ambassador or representative, and so on. In the single subpage, the complete description is simple and allows latitude to adapt. As an example, in the “People Person” page there is a welcoming text that says “Remember that you have complete freedom to do less, more or different tasks in the many projects and teams. Only your imagination sets the limits.”

A similar approach appears in the Funambol participate page. While simpler, it conveys a similar message: participation is not exclusively about code.

We can provide, based on these examples, a few suggestions to improve your project visibility in this area:

• Explicitly mention the opportunity to participate in your project, and if possible add a participate page to your website.


• Before listing what you want from others, think about what may be considered a contribution, even if it may be small. For example, mentioning the use of your project's software can be considered the smallest, but still a significant, form of contribution. In the case of Funambol, it provides an indirect economic value to the commercial project that is based on the open source code base, as it demonstrates market viability and the fact that there is an established user base.


• List explicitly all the possible contributions, and for each present an example. Instead of simply mentioning “graphic contributions”, list a set of possible tasks, like “a new splash screen”. Try, if possible, to list potential contributions of different sizes, listing the easiest ones at the beginning. This provides an immediate frame of reference for the amount of time or effort that may be necessary for a contribution, and gives even first-time participants the opportunity to work on small activities.


• Whenever possible, provide tools for specific tasks. For example, Bazaar provides a translation tool that helps in creating localized strings. In larger scale projects, creating a sub-project for a specific activity may help in coordination and in reducing duplication of effort.

There is a huge world of potential contributions, and just a little effort is needed to assist potential contributors in materializing those potentials.

There is More than Code in Open Source

Today's columnist is Carlo Daffara, the Italian member of the European Working group on libre software. He writes:

Even among researchers, when you talk about “contributions” to open source software you invariably talk about code. Packages, patches, lines of code, whatever: code. In my view, this is quite restrictive, and it is important to start to think about all the possible contributions that are outside of pure code, and how to incent these contributions within projects.

When we think about an open source project, what types of contributions can we find? During a presentation, Aaron Seigo of the KDE project discussed these:

• artwork


• documentation


• human-computer interaction


• marketing


• quality assurance


• software development


• translation

Software development is one of the aspects, but not the only one. After all, if the software is ugly, few people will use it. If it does not work in your language, you may find it less useful, and so on.

Matthias Mueller of the Open Office project published an interesting graph with a similar story. The graph shows the number of active participants in each OpenOffice.org project, with each area proportional to the number of committers. In other words, the larger the area, the more people are active in that area of contribution. The yellow area on the left is related to code, while the coloured part on the right is related to everything else. If you look carefully, you will find that the number of people working on the code aspect is less than the “non-code” part!

In a report published in 2006, one of the project managers of OpenCascade.org (a sophisticated library and toolset designed to create computer aided design (CAD) systems, based on the commercial CAD sold by Matra Datavision) published an interview. Among other things, it stated: “In the year 2000, fifty outside contributors to Open Cascade provided various kinds of assistance: transferring software to other systems (IRIX 64 bits, Alpha OSF), correcting defects (memory leaks…) and translating the tutorial into Spanish, etc. Currently, there are seventy active contributors and the objective is to reach one hundred. These outside contributions are significant. Open Cascade estimates that they represent about 20% of the value of the software.”

The reality is that non-code contributions are significant, and should be encouraged in any possible way. In your open source software project, create a place to help those that are willing to give you more than source code, because that value will get lost if not properly collected. Even small things, like knowing that the code is used by someone, is a positive contribution.

In the next column, I will talk about possible strategies projects can use to improve non-code participation.