New software technology, whether PC or mobile, is now dominated by open source.

Android, Chrome, Symbian , Webkit, Apache, Eclipse, Meego, Linux, Limo, Ubuntu, Mozilla, QT, Phonegap collectively and individually are powerful forces that determine not only the future directions of technology, but by implication the future successes of companies involved in any of the industries touched by these projects.

This article has a singular purpose: to explore the optimal  shape and structure of a successful open source.  And by success I mean not only, where is it today, but are the incentives there to sustain interest and development in the platform. For every open source success, there are many stagnating in a source code repository graveyard

In the context of webinos, the project I am currently working on, this is relevant for two reasons

  1. We need to build on top of other open source operating systems. When we make the selection of which platforms to prioritise, we need to be aware of the risks and benefits of different open source project configurations
  2. Webinos will itself be and open source project. When we construct the mechanics of its operations, we want to do so based upon best practice.

The reality of open source projects is that they require significant investment: hundreds of thousands of man hours in many cases. And this investment is in most cases corporately sponsored. Corporates require a return on investment; whether you can see it or not the company investing effort into a collaborative initiative such as an open source project is doing so for financial gain. Moreover, corporates are “compelled” to compete; shareholders expect returns above the market norm.

These considerations are essential if we are to build a sustainable healthy, open source community.

A successful, sustainable open source community requires that multiple competing companies must continue to invest, on an ideally equal basis, into the collaborative activity.

In this article, therefore I am going to cover several points.

  1. Go over some of the theoretical background on and why companies do (and don’t) invest in open source, and also look at the principle dimensions of how they are legally constructed
  2. Business models: an effective collaborations of corporates, more so than individuals, requires that all parties are comfortable with each others motivations. Why am I engaged? Why are you engaged?
  3. Finally, Ill look at some evaluation metrics – can we establish the parameters by which we can evaluate the probable sustainability of an open source project. And to validate this look at how different platforms measure up.


Background concepts – Why

First let us just review some baseline theory. Why do we think companies engage in open source? What are the incentives and the disincentives to code collaboration? Let’s look at this at the abstract level before we go into the detail.

Software (source code) is a liability

Software developers don’t like hearing this, but there is a great deal of truth in the statement that Source code is a liability not an asset.

If I’m in sales I like binary code. Binary code I can put on a web site of ship as a CD, and people will pay me for it. To the accountant this is an asset: it something that generates income every month and goes towards the bottom line.

But the salesman and the accountant don’t really care about source code. They often don’t know what it is. All the salesman knows is he can’t sell it. And the accountant knows that source code needs these expensive things called programmers to nurture it, and make it grow. Source code is therefore a liability; it costs money every month for as long as own it. (It also depreciates really fast!).

If this is shocking to you – I apologise. But I think once you understand how the business people see it; you might understand why software departments keep getting “outsourced”. They are taking the liability off the books, but hope (usually erroneously) that they are keeping the asset.

And if that shocked you, the next bit is even worse. If you are part of a company that just “open sourced” their software, as a right-on software developer you might think cool, my company has got it – they finally understand this technology thing! Well I’m sorry to disappoint you, but in my experience from the business perspective you just got outsourced again, but this time to magically sustained community which they didn’t have to pay for. It’s a no brainer.

Ok, so the reality is probably a little more sophisticated than, but you get the point.


Game Theory, Economic Theroy

Second bit of theory: Game theory.

I’m not going to give you an ABC of Game theory here, but if you ever want to truly understand Open Source dynamics, or any form of standards activity you need to understand it. A lot of the ideas in this article, will make a lot more sense if you have.

Translating one of the key principles, Prisoners dilemma, into the code collaboration space in a few lines is:

Company A and Company B have 20 programmers each they can collaborate on open source (standards) or create a proprietary system
  1. If Company A and B both put all their programmers on open source, they’ll share the rewards and anticipate making $10million each next year
  2. If A and B both create proprietary systems, we will have a fragmented mess, the market won’t grow and they’ll only make $2million each next year
  3. BUT if one company goes open source and the other creates a propriety system, the open will only make $1million but proprietary makes $20 million.

So you’re the CEO of company A: what do you tell your programmers to do?

If your answer is well we pretend to do open source (put one programmer on it), but secretly create a proprietary system (put 19 programmers on it) –then you have the devious type of mind well suited to corporate strategy!

Now add another 20 companies to the scenario above, can create few other sub-options of choices and your starting to approximate to the real-world strategic landscape facing a corporation deciding on whether to join an open source project

The other concept from economics you need to understand is “free riders”. That is benefiting from the efforts of the community, without giving anything back in return.

Translating again:

Company A, B and C all have 20 programmers. To start they all put 60 people on the project. Six month down the track Company C pulls 10 people off. Company still benefits just as much from the collective effort but has now freed up 10 programmers to put on strategic projects that give them ac competitive advantage of Company A and B.

So your CEO of company A and B , what do you do in reaction?

The problem is I get a tangible return for taking someone off the project, but I will not get a proportionate return for adding someone the project. The consequent regress to zero, and the deterioration of the public asset, is reminiscent of the other economic concept to consider: The Tragedy of the Commons.



Value Chains – Value networks

Final bit of theory for background research is another economic/strategic concept; the concept of value chains and value networks.

It gives you a set of theoretical tools for understanding how commercial advantage in a market can have impact on markets upstream and downstream of this market. And when you factor in that your competitors may share suppliers/customers with your or be segmented differently, you will start to see complex ecosystem effects.

In the area of operating systems, devices, application ecosystems and media markets these interdependencies and dynamics can be mind bogglingly complex.

As a simple example

Company O1 and O2 are in the operating system business. Company D1 is a device vendor is a customer of O1, that’s who they buy their operating system from. Company D2, another device vendor buys a cheap operating system and launches it open source in the operating system market. Suddenly O1 and O2 are now in trouble, they can’t make money. D1 also suffers because their supplier is in trouble


Perhaps now you can see how Open Source can be used offensively. How it is possible to take out a competitor by open sourcing components that may even be upstream from where you and your competitor currently compete.

Can you think of any real world examples where this has happened :).




This is just one example of how to interpret some of the profound effects of open source projects on complex ecosystems




The four critical dimensions of open source

In the context of “corporate adoption” there are four critical legal dimensions that need consideration.

These are the principle variables against which a corporate is going to evaluate the risks and opportunities of engaging in an open source project.

For new open source projects, they are the critical legal design considerations in the construction of the working organisation – and for webinos the problem we are trying to solve is: what combination of these four elements is more likely to result in a well-resourced, well utilised, successfully long term project.


Inbound license

Typically an open source project requires a “contributor” to make certain warranties of on their contribution. In other words they promise that the code they contribute to the project satisfies certain criteria. Usually this contribution license stands as a separate document, however sometimes, as in the case of GPL, it is a set of conditions specified in the distribution license, that you must abide to if you change the distributed code (in other words the inbound contribution conditions are tied into the outbound distribution license.)

An inbound license typically expects the contributor to state that:

  1. The contributor has the authority to make the submission
  2. The contributor licenses any essential IPR to users of the code
  3. The contributor licenses the copyright to users of the code
  4. Some limitation of liability of the “fitness” of the code e.g. “You provide Your Contributions on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.

The inbound license is the first thing that a CONTRIBUTOR to the project must think about

Outbound license

The outbound license defines the terms under which the code is made available to 3rd parties.

The outbound license is the first thing that a USER of the open source code must look at. Within this document it will be described what you can and cannot do with the code. If you are a corporate looking to create derivative projects you can exploit commercially, this is a critical issues

Governance model

An open source project, and more specifically the source code assets of that project, is generally maintained by one collective entity somewhere on the internet. (We will for the moment ignore the more complex scenarios where forked projects are created).

This collective may be formal legal with strict rules of behaviours, or be a loose collection of individuals where the rules of engagement are much more fluid. Whatever the formal construct behind these individual contributors the culture and dominant behaviours of this collective, are essential in determining whether a corporate is going to engage in the community.

The question at the back of the mind of the potential collaborator is: if I invest time/money into this initiative:

  • Will my efforts ever see the light of day? Will contributions be expected?
  • Will I be able to influence the future roadmap of this project? Can I ensure that the project will continue to serve my organisational requirements?
  • Is one of my competitors going to be in a position of power over me, and/or can they deliberately/inadvertently do me damage by forcing the project in a direction which is not to my advantage.

Many open source projects will address these questions by stating that all such decisions are taken on a meritocratic basis, where key positions are given to people not companies, based upon their peer accepted valuable contributions. Although this may be true in some instances, we must also be aware when engaging with a corporate entity, they would be doing a disservice to their shareholders, if they did not at least consider the material risks to their company if this meritocratic systems was being “gamed” by one of their competitors.

Trademarks and compliance

The final legal dimension we should consider is the use of compliance processes and trademarks and a further constrain the use of derivative works, which can be essential to controlling the long term direction of an open source code base, and to stop the code asset from forking in the wild

Mozilla and Android both use these techniques, but in subtly different ways, to constrain the real world use, of what would otherwise be highly valuable assets, that are released under notionally permissive licenses.

Diagram outline the legal control points of an open source project.


Open Source Business models: simple money making


Now we have covered some of the essential theoretical background to open source, let’s turn our attention to what makes it all tick: money and power.

As a quick clarification: there are many, many open source projects out there, which have been created by one or two people in their spare time and have been given away free, gratis to the world at large. This is a worthy goal, and an activity I have been involved in myself from time to time, but this is not the focus of this discussion. The focus of attention for this article is specifically on corporate sponsor open source requiring tens or hundreds of thousands of man hours or more to make work

To build a thriving collaborative community, you need to trust the motives of your collaborators. Therefore a detailed understanding of what theses might be is essential. I shall break this down into two parts

  1. Above the water motives: different ways of making money directly form open source
  2. Below the water motives: indirect ways of making money from open source

Type 1 motives, you can find plenty of examples out there on the internet. I will touch on each briefly, just for the sake of having an easy to find summary. Type 2 motives you will fines less well represented, but not less important for that.

To make money from services



One of the simples and oldest of Open Source business models. Developer invests in the core OS asset at their own expense, but then generates revenue from users of the Open Source asset that needs some “pain taken away”.

The typical pains is “How do I find out how to do XXXX quickly” – in other words a support contract.

The classic example of this model is canonicals support contracts that is sells to support its Ubuntu distributions


To make money from consultancy


A subtle variant on the above model where the company charges users of the of the open source asset consultancy fees to help them get best value from their software

  • Nitobi is an excellent example of how this business model can be used effectively. They give away the excellent PhoneGap software for free, then provide consultancy to companies wanting help in using this software
  • IBM arguably, at the much higher and of the market adopts this model. IBM invests heavily in open source projects, through the manpower they make available to them. IBM of course has many business models, but certainly appears to be making adequate return on this investment through bespoke consultancy work it generates. Many customers of which are of course already using the Open Source components that IBM has a substantial stake in.


To make money from hosted service



Cloud computing has opened up new business model opportunities. Many open source projects are very powerful and contain a lot of features, but can be incredibly hard to set up and configure. Some companies taking their primary, open source asset, configuring them out in the cloud, and providing users access to their capabilities, though web services as a cloud based subscription or pay as you go method.

Again Nitobi stands out as an excellent example of how this business model can work. Their newly launched PhoneGap Build service takes their existing service and makes it available on a cloud basis for a subscription fee. This model is particularly appealing for Phonegap users as their core product is a cross platform application build tool, and to run effectively would require an end user to install 4-5 different SDKs on their machine. This model circumvents all of this and provides fully compiled executables over the cloud service.


To make money from license


So here’s a puzzle: how do you make money from licensing and open source asset?

Answer is you “dual license” it.

What does this mean? Basically, you offer the asset in two variants:

  1. One version is free – genuine open source – but typically there is some limitation to or something undesirable about that license (see below)
  2. One version is paid – and is usually highly permissive, essentially a normal commercial software license

So how do create a license that is limited or undesirable. I am aware of two common variants of this

  1. Academic licenses. ,e.g. that contain the magic wordsNeither the names of Licensor, nor the names of any contributors to the Original Work, nor any of their trademarks or service marks, may be used to endorse or promote products derived from this Original Work without express prior permission of the Licensor
  2. GPL: for reasons that are explained towards the bottom of this article, there are classes of potential users of open source, that fear GPL like the plague. They will happily buy themselves out of this constraint.

One important caveat to this technique. You need to make sure all contributions are made via an explicit contribution license that gives you (the manager of the open source project) the right to relicense. You cannot rely on the normal LPGL/GPL obligations, as these do not give rights. Without this explicit right, you will not be able to absorb third party fixes into your commercial product

QT is a good example of how this business model works. .


To make money from Upsell


Upselling complimentary software products is another common business model. The proposition is very simple: OS assets are given away for free, but extras, add-ins or complementary products, which add much needed value to the core asset are charge for.


To make money from Hardware


One of the more interesting trends in the past few years is companies looking to monetise the end to end product, more specifically the hardware on which the product runs.

Boxee is a great example of how to do this. The source code, which is based on XMBC open source project, is available for free. But if you want a shrink wrapped ready to go box, you can buy the product

There has also been a number of network routers following this model with their hardware products.


To make money from Advertising

The final model I shall cover, possibly the most complex: is money from Advertising.

The premise is simple: open source code is released and packaged as product. The organisation behind the project then receives kickbacks from “complimentary” services, the most obvious of which is advertising, or advertising related revenue.

Mozilla is by far the best example of how this can be done. The Mozilla financial statement of 2006 shows that according to Wikipedia

In 2006 the Mozilla Foundation received $66.8 million in revenues, of which $61.5 million is attributed to “search royalties”.

Specifically, when you use the Mozilla search bar, traffic gets pushed to Google, and Mozilla receives a financial kick back.

I believe Mozilla’s income is now distributed over a few other sources (not just Google) now, but when people start comparing Mozilla to Google Chrome, it is worth keeping these facts at the back of you mind: Mozilla is in effect no more than a parasite living of its host, and could be shrugged off quite easily!

But at a general level the critical question is: how are these revenues maintained? What is to stop someone creating a derivative product that removes the advertising hook, and creating their own, diverting the money flow.

I will not pretend that I know the complete answer to this question: but essentially it is a mixture of

  1. Effective use of trademarks
  2. Backed up by loyal existing customer base
  3. Backed up by a strong set of contributors that act as both centre of gravity and gives the product strong inertia that makes the risk/opportunity analysis of forking the code base


Open Source Business models: Dark commercial strategic motives


In the above section I have covered the motives for a corporate engaging in open source that lead to direct money flow, back to the corporate.

This is interesting but there are fact a whole set of other motives for engaging, that are not “directly” revenue generating.

The motives are listed one by one below. These motives are not mutually exclusive and some of the motives overlap and often many can act in concert to create a compelling reason to engage.

Hopefully, this will be useful in understanding, what is really going on behind the scenes.

Health warning: I will make reference to specific companies below, but please remember we are talking about “presumed” motives here. All is supposition only. Also most examples are going to come from the Operating System or Web browser runtime areas, as these are the technologies I know best.

To grow ecosystem


Earlier, I introduced the value chain and value network concepts. For the Operating system example it is clear that the OS exists in an ecosystem where the value of the OS is influenced strongly by

  1. The number of devices that use the operating system
  2. The number of applications that run on top of the ecosystem

The theory is

  1. If the operating system is free (open source), device vendors will be more likely to user is
  2. Application developers are more friendly to open source operating systems than closed systems

Therefore in this context “open sourcing” is a strategy to grow the ecosystem around the open source project. This presumes of course that the backer of the project has other motives for increasing the reach of the project.

Android, I think ticks all of the boxes implied above. In fact the following diagram is taken from their compliance program, underlines this perfectly:

This example relates specifically to the ecosystems surrounding OS, Apps and devices. I believe however the motive and strategy will transpose well onto other tightly coupled ecosystems.

To control ecosystem



Again, using the Operating System example, it is clear that operating systems are a powerful control point in the ecosystem.

An operating system puts constrains on the physical hardware devices that can run on it, it also determines, controls, enhances the functionality that an application has access to.

Using the Android example again:

  1. Android has a very stringent compliance tests that device vendors must pass if they want access to the premium (non open source) apps – such as market place, maps and search., for example, claims they were denied the Market for a lack of a camera and compass. is a clear example of how Open Source proliferation, backed up with the commercial ratchet points (trademarks, compliance, ecosystem access) can fundamentally effect the hardware devices entering the market
  2. Similarly when the OS project has been legally constructed correctly, the OS adoption grants back to the primary developer the ability to determine the size and shape of all the applications that now pass over the system.

This “Motive” only becomes active if the OS achieves reach (market penetration). But if it does it becomes a very compelling commercial motive indeed. It gives you leverage on the entire ecosystem north and south of your point of intervention.

To Enter Market

Imagine you are working in an industry where there were 4-5 dominant players. Imagine that the products in this space represented 100 of years of man effort and that the ecosystem was tightly coupled, with entrenched long term relationships between suppliers and vendors. Imagine you wanted to enter this market, to accrue some of /all of the benefits outlined elsewhere in the market. How do you do so?

Again this is where the open source strategy can help. Especially in markets dominated by proprietary players, the disruptive influence of a free open source component, can help speed up the adoption process significantly. In retrospect the rapid uptake of Android by the market can be seen to have been helped by this dynamic.

It is important to note that “hypothetically” this strategy can be used to “enter the market” but does not mean that the new entrant stays “open source” permanently. For companies that hold the right to “re-license” the core assets unilaterally, it is possible to enter and disrupt the market, then at a time that they see fit, chance the license back to a propriety model.

Or more gradually, source code can be made available under dual license, where the commercial code is handed out well before the open source branch, and this competitive lead time can be lengthened out over time, until the open source branch becomes almost defunct.

The Foundation model



The foundation model is an odd one, in that it is not a direct motivation for a company to engage an open source project per se, unlike all of the other strategies listed here. But it is a common tool used to resource administration, as well as having designed in, strategic reasons to engage.

The basic premise is this: there is considerable overhead in running a successfully open source project. This overhead needs resourcing to cover. One way of fulfilling this resource is to charge fees for member of the foundation. But there must be some quid pro-quo. This comes broadly in two forms


  1. Privileged influence: a member is granted access to certain committees that allow it to influence the direction of the organisation
  2. Privileged usage rights: coming in the form of advanced information or in extreme cases a different source license that the code is available under.

Of the top of my head I cannot think of a single foundation that generates enough revenue through this mechanism to cover the programming resource required to execute the project, therefore one of the other motivations described in this articles, still has to justify that larger scale investment. But it is worth recording this further dynamic in open source community operations.



The Benefits of Linux Foundation Membership

  • The ability to participate in Linux Foundation member-only activities like the Linux Foundation Collaboration Summit and Legal Summit to learn, influence and participate with the Linux Foundation workgroups
  • The right to vote and run for Linux Foundation board seats and influence the direction of the organization

    To devalue competitions assets (focused)

        Here is one of the more devious applications of an open source strategy. In a previous life I confess to being party to these type of discussions on at least two occasions – so it really does happen! This is the scenario: Company A and Company B compete with each other in the same market. Their product is complex, consisting of many interworking parts. Company A is strong in one area (Component 1) Company B is weak on Component 1 – but strong on component 2. In this scenario , it would be a perfectly rational strategy for Company B to open source its version of Component 1. This has the dual effect of
  1. Completely “de-valuing” Company A’s key strength.
  2. In consequence giving Company B a stronger, more highly differentiated competitive advantage.

Pursued to its extreme, this can lead to counter move by Company B, leading to an eventual Mutually Assure Destruction of the entire market (or at least the proprietary elements of it).

This strategy has been outlined for two directly competing companies. Am sure if you think really hard you can find other examples where companies working outside the typical market (but who have a vested interest in it) have deliberately/inadvertently destroyed the dominant players in that market


To remove license costs


This model is a little more esoteric, and specific to the way the industry is set up, but in that it represents a significant piece of Symbian history, it is worth recording for prosperity. You never know – it might happen again.

Once upon a time Symbian was a private company, owned by shareholders. The shareholder distribution represented the vested interests of a number of parties that wanted to “collaborate” on the shared asset. Nokia was a shareholder in this company but also, as time went on, its only significant customer. Now because Symbian was a company, customers of Symbian had to pay them a license fee – even if you were are primary shareholder. According to Nokia at the time of the Nokia-Symbian acquisition, was paying out $250 million a year, in licensing fees, effectively subsidising it competition. The price to buy out Symbian at $410 million, especially when you get a cheap loan of €500 million from the European Investment Bank (EIB) is a no brainer.

By putting these assets as open source, Nokia could then utilise the code without paying a license fee, and the open source collaborative nature of the project would allow the costs to be shared, as per motivation described below.

To share costs

The final motivation to be considered, any by far the most common, harks back to our “software is a liability premise” we started with. Simply, code is open sourced to share costs.

Of course to share costs, we need to make sure that the motivations exist for competitors to “lend a hand” to our cause, which now brings us full circle back to:

How do we build a sustainable collaborative open source project?

What would a sustainable open source ecosystem look like


Based upon everything we have learned above, what are the key elements that an open source project must possess in order to

  1. Get enough initial active participants to start the project
  2. To sustain the participation, in a balanced way, to keep the project collaborative, and keep key competitors engaged.
  3. Generate enough interest or (generate enough revenue) to deal with the boring administrative issues also.

The key risk factors – what we need to avoid:

  1. Companies refusing to adopt the code, because of competition of IPR risks
  2. Companies refusing to contribute to the code because of IPR risks
  3. Companies dwindling away from contributing , which over the long term will lead to fragmentary competitive initiatives, due to competition concerns.

I’ll start by listing out what I think these qualities are, and as a sanity check on these compare them to some existing open source projects. But as I shall repeat at the end of this article this is work in progress and feedback is very welcome

License – Non GPL outbound license

I stated earlier that many companies (especially hardware companies) fear GPL like the plague. I’m sure there are hundreds of GPL advocates out there, who will be very keen to explain to me that this is complete nonsense. Whatever the real theoretical truth of this statement – I can guaranteed you from the time I spent as CTO of OMTP and WAC negotiating IPR and licensing contracts with member companies – the fear is very real.

This area is really the domain of IPR legal experts, but here is my translation of the perceived risk that companies have.

  1. If I use a piece of GPL code and accidentally combine this with my proprietary (competitive advantage) source code, then I am compelled to release my entire software stack into the public domain. Will I be infected by the viral license?
  2. If I contribute to a GPL project, I am under the terms of the GPL granting a license to any user of this code to any IPR I hold. Whilst this patent license only holds for the code contributed, it then means that a competitor can, by using this code, get free rights to critical parts of my patent portfolio. You must remember that patent disputes between large corporates hit the 100 of millions to billions level, you understand even if the risk is 1%, it is still financially material risk.

There are some companies out there that will require almost board level approval before a single member of their organisation can contribute to an GPL open source project. Such is the fear level

Independent licensee – Incoming license

On the inbound side it is essential that the assignment of licenses is made to an “independent entity”. Ideally the legal entity that represents the Open Source Project. And this must be combined with the clear, balanced governance (next point).

The reason for this is simple, if I want broad industry participation to the project, I cannot give unfair advantage to any single player.

If you contribute code, and assign a license to a competitor (of course depends on the specific contribution license). This competitor can do almost anything they like with this code – including licensing it commercially.

Balanced governance model

To most contributing organisations a balanced governance model will be a critical deciding factor on whether they contribute to the project or not. If I am going to invest my resources into a project, I need to feel that either

  1. Best case: I have a significant chance of influencing the direction of the open source project to my companies advantage
  2. Next best case: there is no undue bias in the project, and open source project will move in a “best for all” direction

The absolute worst case is: my competitor has undue influence on the project. This will ring alarm bells.

Fast governance model

An almost diametrically opposed criteria is: can the organisation make fast decisions.

Between Fair and Fast there is a difficult compromise to make.

Resourced Administration

Is the project sufficiently well organised or sufficiently well-funded to resource all the difficult administration that is required to make the project a success?

Resourced Contributions

And finally, the most difficult question: is there a belief that the project will be sufficiently well resourced to deliver and to continue to deliver on its objectives.

This final criterion is in fact the fundamental test of the “sustainability question”.


Now it time to test some of the theory outlined above. Several prominent open source projects are listed out below, lets see how they measure up against our current evaluation criteria, and see if it passes the sanity check.

Remember the question we are asking is: does the project possess the qualities to encourage sustainable collaborative development. This means many different companies contributing on a relatively balanced basis

(Contrast this with (a) Will a company use this code base in their products (adoption) (b) Is the project “unilaterally” resourced from a single contributor – these are not the questions we are asking at this stage.)


Non GPL Used Symbian Foundation license and Eclipse license – fit for purpose
Independent licensee Symbian foundation was the receiving party. Theoretically independent
Balanced Governance The processes, by design were very fair. Unfortunately the “incumbent” chairs were predominately Nokia, giving a real world operational bias.
Fast Governance Did not run long enough to see how it fared. But was slow in the early setup phases (but that should be expected)
Resourced Administration The foundation was very heavy in terms of administration. I don’t think the funding model would have supported it long term
Resourced Contribution Had the foundation survived, because of the Nokia dependence on the platform, you would have had a relatively high confidence that the contribution would be resourced for some time.


The Symbian Foundation is dead, so this analysis is an exercise in post rationalisation. But a useful test none the less. I confess to always having a soft spot for Symbian. I think the core technology was good, and the intentions on the open source side (relatively) pure. I believe it was a victim of lack of trust and bad PR. The deeply entrenched strategic corporate double guessing of intent, such as outlined in some of the discussion above, meant that in reality – no one trusted Nokias intent (or maybe long term support) of the platform. This is all pure speculation – but it’s important to learn lessons from the failures.


Non GPL Dual licensed – so it does not get a red mark. But if you want to escape the constraints – you have to buy yourself out. Not really the spirit of collaboration.
Independent Look at the contribution agreement below. Very few companies will be motivated to sign that
Balanced Governance Historically Nokia was 100% in control seems to imply this was to change. But I cant find the results
Fast Governance Actually not sure, but my guess is fast. It will get slower if they do open up!
Resourced Administration Nokia underwritten
Resourced Contribution Nokia underwritten


The killer for QT is the contribution license

THIS CONTRIBUTION AGREEMENT (hereinafter referred to as “Agreement”) is executed by you (either an individual or legal entity) (“Licensor”) in favor of Nokia Corporation

There are a large number of companies that would have real problems signing such an agreement. Therefore it does not seem a contender for balanced cross competitor collaboration.

I have been generous on the assumption of resourcing from Nokia. However, previous supporters of Symbian may have the “once bitten twice shy” philosophy.

With the current confusion surrounding

  1. Nokia and Microsoft relationship
  2. What do Digia control vs Nokia

Clear communication is required, if others are to have confidence in the long term future of the project.



Non GPL Its mostly GPL – but it Linux so there is no choice. It does not get a red mark
Independent As its GPL – there is not licensee, control and future comes down to community gravity, trademark, ecosystem binding to stop fragmentation
Balanced Governance I’m going to leave this blank for now – as I need to more research
Fast Governance Ditto
Resourced Administration Assumption between Intel and Nokia there is enough resource to keep it ticking over – but same caveats as for QT
Resourced Contribution Ditto


Again the Microsoft Nokia relationships are creating FUD in this space. Clarity is needed asap to inspire the confidence that will make the project a success.

Second consideration: there aren’t may devices out there, and there does not seem to be many in the funnel


Non GPL Apache uses the Apache license generally. A wonderfully permissive license.
Independent All rights are licensed to the Apache foundation.
Balanced Governance Devil is in the detail, but unless anyone can provide me with a counter example, it seems the foundation runs a pretty meritocratic, well balanced process
Fast Governance Apache endorses a principle of “lazy consensus”. A highly pragmatic approach to getting the balance between fast and fair
Resourced Administration Apache sponsorship model seems to generating enough revenue to keep its lightweight processes above water
Resourced Contribution I think this has to be measured on a project be project basis



Non GPL Some of its GPL some of its BSD. But low risk from an IPR side of things if webkit stays scoped on HTML rendering as its insulated by the W3C patent policy.
Independent Licensee There is no direct licensee
Balanced Governance Governance is meritocratic, based on contributions. In effect that means that the company investing most in the project has greatest control. Need some hard figures to work out exactly what the status quo is.
Fast Governance Needs research
Resourced Administration Don’t know
Resourced Contribution Don’t know


Non GPL The license is pretty permissive – only thing to consider is the restrictions that the trademark policy will have on real attempts to create derivative works. Needs a little more analysis
Independent Licensee The Mozilla Foundation – an independent legal entity
Balanced Governance But we should not forget where the money is coming from. Any organisation is susceptible to implicitly or explicit pressure of the money flow is constrained.
Fast Governance I assume good.
Resourced Administration Mozilla well funded
Resourced Contribution Mozilla well funded plus healthy external contributions.




A lot of material has been covered in this article, we have looked at

  • Some of the general background theory on Open Source dynamics
  • The key legal variables to be considered in constructing an Open Source project
  • The direct financial incentives that corporates have for engaging in open source
  • The indirect strategic incentives (and by implication risks) corporates have for engaging in open source
  • A set of hypothetical criteria for evaluating the “sustainability” of an open source project, which implies balance
  • And sanity check of these criteria against existing projects, to see if they make sense

Remember all of this was done with a specific purpose in mind. We have a problem to solve, which is to construct a new open source project – webinos, which has the best chances of success.

Within the webinos project, there is a formal deliverable (2.6) that will make definitive recommendations on these subjects. This article is not that deliverable.

What we need is input. What do other people think about these subjects?

I hope you find this useful. Feel free to give feedback, either publically on this blog, or email to or me personally at