There are a number of commercial reasons why a company may choose to make a project ‘Open Source’.
The following sections can be used as a guide to help decide whether a software project or component should be developed as part of an Open Source project.
‘Open Source’ is related both to the idea of developing software such that it remains within the public domain, as well as the idea of fostering the free, collaborative labours of other developers interested in contributing for their own benefit. The latter cannot occur without the former (or a large amount of money).
In the following, an Open Source project is one that adopts the principle of developing software that remains in the public domain in order to enjoy free collaboration.
This is not about hippie/hacker culture, it’s about commercial expediency and competitively advantageous co-operation.
The prime commercial reasons are:-
If a company needs a new or enhanced tool or technology but it wouldn’t be economic, strategic or possible to develop it internally, then as long as it is highly likely that many other companies or members of the development community see the same need (whether or not they would have an interest in an internal development) there may be a commercial advantage for that company to initiate or part-fund an Open Source project.
If a company can define a project and get a hundred or so programmers happily working at no cost to itself on this project, and in conjunction with a standard Open Source license have commercial advantage from the software so developed, then this is a huge saving on development costs (potentially saving many hundreds of thousands of pounds).
This also applies even if it is necessary to provide some resources to start the project going, or to co-ordinate the free labour for a while if it is likely to end up being entirely self-sufficient.
An Open Source project has the potential of getting the very best programmers working on a project. The "world expert" may live on the other side of the planet, he may be extremely interested in the company or projects, BUT if he is NOT willing to move to shared premises, being Open Source lets him join the project.
Teleworking can develop from this, e.g. if a good Open Source programmer emerges they could then become a paid teleworker working to specific goals.
Programmers know that their work (if good) will last in perpetuity and will not become the intellectual property of another organisation. The programmer may now totally satisfy their self-interest, produce their most excellent work, knowing that they will never lose it, and that they will be valued according to the quality of their work rather than meeting the terms of a contract.
Because code is now selected upon its merit as opposed to its timeliness (despite timeliness remaining important), this will have the effect of producing quality software over time, as opposed to poor and increasingly unmaintainable code.
Given the slow rate of recruitment, it is possible by going down the Open Source route to "fast track" a project and catch up on the competition (larger companies) and due to a reduced wage bill undercut the competition.
There is also a very reduced ability for a large company to stamp out an Open Source project that threatens its proprietary product. Because it is in the public domain, it becomes very difficult to prosecute many individual contributors who are able to restart the project at any time.
Given the potential growth, public image and word of mouth communication, it is possible to establish "a world standard” sooner. This can result in increased value in the company and can create a market for proprietary tools and services.
Altruism and philanthropy might give the initiating company a warm feeling inside, and even improve its image in the community, but they are not usually prime commercial reasons. Nevertheless, there can be marketing benefits to companies that appear to be contributing something for nothing to the software industry. There is still some mileage left in the Open Source bandwagon, and it will take time before many people realise that it’s been commercially sound all along.
The criteria that need to be met are:-
One cannot commence an Open Source project with only a vague notion of what it would be.
One must have a clear idea of the goal of the project, and the method and strategy by which it will be approached.
We must understand the advantage of going Open Source.
The project must be useful to the initiating company, but be uneconomic to develop closed-source, i.e. the benefit to the company minus the benefit to the competition and costs of the project being Open Source must be greater than the benefit minus costs of closed-source development.
The project must produce something of interest or benefit to the wider community, particularly where this would be likely to result in contribution of work or funding.
The areas of the community likely to be interested should be identified, e.g. commercial sector, academics, government, military, etc.
Do not re-invent the wheel.
However, the flywheel, Ferris wheel, Catherine wheel, and steering wheel, would be fine adaptations, as would be improvements such as spokes, the pneumatic tyre, or the carbon-fibre monocoque.
If there is already an Open Source project with the same goals, then either the new project must use a better approach and be likely to deliver sooner than if it collaborates with the existing project, or it should indeed collaborate with the existing project.
If initiating a project is part of the commercial advantage, then this will have to be reviewed if collaboration is warranted.
Once given the go ahead:-
The license or licenses must be drawn up for the project’s software components.
The license should be chosen that maximises the benefit to the company, yet does not jeopardise contribution or future collaboration from other parties.
NB Open Source is all about self-interest, i.e. community collaboration improving the benefits to the self-interested collaborator vs going it alone. However, if it is desired to retain control of software or restrict benefit to the rest of the community in any way, yet there are some benefits to making the source code available (for public escrow say), then it is doubtful that Open Source is an appropriate development model.
Any need to restrict the identification of the software in terms of name and logo can easily be built into the software license or a separate trademark license, say. However, this cannot stop someone taking the software and using a different name and logo.
The company and project team can be associated with its project for as long it wants to. There is no need to protect this association.
However, one cannot restrict anyone else from forming their own team and starting a different variation of the software (a fork). For example, Sun have tried this, but there is much dissent in the Open Source community, so perhaps they won’t be expecting much collaboration. This is really a public escrow approach.
The company name will always exist in their particular Open Source license, or trademark license. There will also always be a historical record of the part it plays in initiating or contributing to an Open Source project and the software. And whilst the originating company can clearly demonstrate their pre-eminence and superiority as leaders of the project, they will only remain able to refer to this status insofar as it is respected by the rest of the community. In turn, there will be little respect for a lesser party attempting to fork the software.
The strategy for publicising the Open Source project and its software at each stage of its lifecycle must be determined for each project. The objectives and audience for each item of publicity must also be clearly understood.
Note that the need to obtain maximum contribution from the Open Source community may sometimes conflict with the need to control visibility of the project prior to publicity of the company’s involvement. Unlike its advantage in proprietary development, of a game say, a secret, initial development phase will delay the marketing of the project to the Open Source community, and thus delay any collaboration. However, there is some scope for obtaining contribution from Open Source collaborators on an embargoed basis as long as they were assured that their contribution would automatically become Open Source after the embargo date. This would require independent escrow during the embargo.
Either there must be a prototype, which in demonstrating current or potential utility is likely to attract contribution by way of enhancement, or there must be a clear technical design proposal for a solution that is likely to be of interest to contributors in implementing and exploiting it.
It is important to maximise the visibility of the project to the Open Source community in order to maximise the likelihood of contribution.
If there are hosting service providers that offer such visibility then they should be utilised if it is cost effective. Some of them such as SourceForge are currently provided free of charge.
In spite of confidence at the level of service provided by the host, one must always maintain a backup of the project, and be able, at relatively short notice, to host the project using alternative facilities.
In order to cement the association of the company with the project and software, it may be prudent to provide the web site that describes and markets the project for developers as well as the wider potential audience.
The whole point of Open Source is that it is in ones commercial interest. A company is still quite able to have its own in-house development of proprietary software that might enjoy the fruits of the Open Source project. Even so, its own developments must not infringe the Open Source license being used.
For example, there is no problem in a company contributing to the development of Linux, yet developing a closed-source application to run on it.
Some licenses such as LGPL would permit the development of an Open Source 3D renderer say, yet allow its incorporation into a closed source game.
The Open Source community has no contract ‘to deliver’. Any contributions arrive at unpredictable times. Despite timely solutions being valued and therefore likely, the only way of improving the assurance of timeliness is to commission the work.
So, the 'cheap labour' comes at the cost of project scheduling. But then, software production has never been easy in that respect.
If a company is visibly involved in an Open Source project that threatens other companies’ products or projects, then this may affect their relationship with them in other areas.
Although it depends upon the license, Open Source software generally cannot be cut and pasted into proprietary software. Of course, such code may be re-written, and one might get around the restriction that way, but it is unlikely to be worth the effort. The whole point of Open Source is that it makes closed use (even into proprietary packages) uneconomic. It therefore doesn’t generally depend upon being able to prosecute license infringement.
Furthermore, any publicity about a company infringing an Open Source license would have a big negative impact on the community’s respect for any Open Source projects that company would be running.
Even a company's legitimate exploitation of Open Source software would have to be relatively carefully managed. If it started 'raking it in' from using proprietary software that exploited the Open Source work, then contributors might get a little jealous. This is why the commercial side may sometimes need to be identified as separate from the technology side.
One has to understand that a company being involved in Open Source projects is about allowing it to take advantage of its competitive ability to exploit the software they produce. It does not uniquely control or own the software, nor should it lull itself into thinking that way simply because it's been working on it for so long.
If the Open Source project will not result in saving, or earning a 'for-profit' company money, or improving its competitive advantage, then it should not be doing it.