I’ve been involved in open source for a long time – probably what might be considered a ‘generation’ in this industry. I was a fan of open source before I even knew the term existed – during my formative coding years in the early 90′s I was always releasing code for free and encouraging people to tell me why it sucked, and doing the same for them. Of course, most of the discussion went on over FidoNet, BBS-relayed emails, the very early (pre-WWW) internet and code on FTP sites, but the principle was much the same.

It was only when I needed a host for an increasingly large 3D engine I’d been writing in 2000 (which later became the earliest version of OGRE) that I discovered Sourceforge and open-source licenses. At that stage, I didn’t really care much about the minutae and just went with what seemed the most popular choice – the GPL. Fairly soon after this was revised to LGPL because it was clear GPL wasn’t a flexible choice for a library. Over the years I formed the opinion that the LGPL was a good balance for what I was doing – it allowed use in proprietary applications but required that modifications to the open-source part were passed on; and this also, I thought, encouraged contributions back to the core since it’s simpler to have your changes promoted. The downside was that the license is pretty long and full of legalese, and frequently needed explaining & clarifying. Still, I considered that a necessary cost of a license that ‘protected the interests’ of the open source project. I had considered more permissive licenses like zlib and MIT to be too weak -  giving everything away with no conditions encouraging reciprocal contributions or participation.

I only really started to seriously question this long-held opinion recently, shortly after I had to deal with a license violation issue. The details of this are irrelevant (and will not be discussed here), the important thing is that after all the dust had settled, it really made me sit down and take a long, hard look at what open source licenses actually achieve in practice, and which bits I felt were the most important for sustaining my projects.

Purist free software advocates subscribe to the view that all software should be ‘free’ (as in speech), which is, when you boil it down, a philosophical principle. While the intention is often genuinely altruistic – enablement for all developers and users of software – in a practical sense it is also a highly prescriptive, black-and-white approach. Free software licenses like the GPL restrict as much as they enable, on the basis that not to do so would deny future users of the flexibility to alter the software. It’s an understandable point of view, if very hacker-oriented, but it’s not one that I personally sign up to. I’m not involved in open source as a ‘movement’, in order to ensure that all users have access to all the source code of every application they use. Instead, I’m involved in open source because I think it’s a damn good way to get good software written for the benefit of the many, particularly infrastructural elements that can then be used to innovate faster, by smaller teams, to challenge incumbents, and generally shake things up. I’m a firm believer that open source and proprietary software can be good bedfellows, and that each can benefit the other – open source providing solid foundations for proprietary innovation, and proprietary software contributing to the open source projects underpinning it, in terms of code and funds. In that context, the restrictive elements of the LGPL seemed well-placed – the LGPL allows proprietary use, but modifications had to be passed on.

But, after much consideration and hard self-questioning in recent weeks I realised something important. Of all the people that have contributed to OGRE over the years, I can’t think of a single good code contribution that has come about because the license conditions encouraged it. All of the people who have made a significant positive contribution to OGRE have done so because they chose to do so. Either because they wanted to do it for fun, or because they saw that it was in their own interests as users, they sent patches in, created new add-ons, joined the team etc. None of these people required any coersion from a license to do what they did, and all the better for it – because they chose to do it, they tended to be more forthcoming in terms of adhering to standards, answering questions about their contribution, and generally participating in the community rather than just doing a minimal code-dump.

The other thing I considered was the impact of someone modifying OGRE and not publishing their changes. On the one hand, this is a potential for a lost contribution, but in practice the LGPL conditions are only to pass on the source to others, not to contribute back to the core project (which requires a contributor agreement anyway), and as mentioned we’ve already established that the best contributions are from willing sources anyway. Then comes the principle of whether it matters that the end user is not guaranteed to see the modified source of OGRE – free software principles say this is not right, but I have to say that in practice, most end users don’t care and in practice it’s of little consequence for OGRE. Obviously many people in the free software camp would disagree strongly with this. It’s more of an issue in enterprise apps where a customer who receives a significantly customised application from a vendor, and needs to keep maintenance in mind; IMO regardless of whether the software is based on open source the customer should be insisting their vendor delivers source anyway – that’s what contracts are for. But I digress.

So, after much thought I concluded that the most useful pay-backs to an open source project, and thus its community, from a user (in my opinion) were:

1. Code & documentation contributions – which based on my experience come from voluntary sources
2. Community participation – forum support, bug reports etc
3. Publicity.

The ‘restrictive’ elements of the LGPL (and GPL), to which so much confusing license text is dedicated, didn’t seem to contribute to any of those except number 3, and then really just as a side-effect.

It was at this point that I realised that my previous opinions about permissive licenses not providing enough safeguards against exploitation for an open source project were off-base. In practice, open source projects don’t really need protection, because their best contributors are going to be there regardless (yes, I realise the GPL provides more protection to end users who want to get at the source code, that’s not what I’m considering here). ‘Freeloaders’ – people who use or modify the open source project for their own ends but give no code or community contribution back – are always going to exist; even under the GPL it’s easy to freeload, if you make your money from hosting services for example, and thus license choice has little impact on the scale (if not the nature) of the freeloading. Besides the annoyance of ‘that guy took my work and made some money out of it’ – which you have to accept as an inevitable outcome of going open source, so stick to making proprietary software if that bugs you – freeloaders have little negative effect on an open source project, and actually their use can contribute positively to item 3 (publicity). The key is to recognise that in practice you can really just ignore freeloaders, and instead concentrate on maximising the positive contributors in your community.

So, if we acknowledge that the people whose contributions we actually want are those who contribute voluntarily, regardless of license, we quickly come to the conclusion that all that really matters is the size of the community. It’s a fair assumption that for a given project there is a relatively stable percentage of users who will choose to contribute back (the percentage itself varies per project, but is fairly stable per project in my experience), therefore the easiest way to increase your contributors is to just increase your user base. Forget about trying to coerce people into being ‘good’ members of the community, just trust that the percentage will be there and will track your overall numbers.

One way in which to attract more users is to make the licensing simpler and more easier to understand. Programmers hate legalese, and a simple, clear license is bound to be more attractive than our LGPL (with static link exclusion), plus OUL option. It’s for this reason that from OGRE 1.7 we’re switching to the MIT License.

I’d like to thank Matt Asay for his post on the subject, which really jump-started my thought processes on this subject in the last few weeks. This whole process has been a reminder to me that it’s always good to re-examine your previous assumptions and opinions in the light of practical experience, and to be prepared to reach different conclusions than you did before. The whole open source landscape is constantly changing and maturing, why should those of us immersed in it be any different?