Using open source methods to reduce the costs of in-house development has considerable potential for many organisations. These range from the relatively easy to achieve (such as through using open source development tools) through to the complex (placing in house developed software into the open source domain).
However, open source development changes many things compared to the well understood (predominantly proprietary) IP model, even for in-house development. Additionally, many of these changes are counter-intuitive and subtle, so it can take a while to fully comprehend how these changes represent opportunity.
A significant confusion that arises when people first encounter open source is why people and companies participate in open source software development projects. That many well known names in the IT world (such as IBM, Compaq, HP to name but a few) are active participants in open source development is fact: the reasons for this participation – and that of thousands of other organisations - is not yet well understood by many orgainsations.
Both companies and people need to earn money to live. So, why are companies and people actively participating in open source development if open source licensing means that they will not earn any revenue from the resulting software?
What's in it for them?
Many people believe that the majority of software development activity is involved in creating software for sale. This is a very long way from reality. Whilst the statistics are hard to pin down, almost every estimate places this 'software for sale' activity at under 20% of total software development - and some figures place it below 10% of all software development activity.
So, if 70% to 80% or more of all software development activity is aimed at creating software that isnot for sale, what software is being produced?
Unsurprisingly, it is in-house development - creating software to meet the specific needs of an organisation - that results in the majority of software development activity.
In-house software development activity results in two sorts of software:-
software that itself provides a significant competitive edge to the organisation, projecting the organisation into its markets and clearly differentiating it from its competitors.
software that provides 'infrastructure' of various kinds – ie software that is essentially a commodity, performing a necessary function but one which is well understood and not of a novel character.
Every in-house software development project has commodity parts - such as data translation between disparate systems, data access tools, monitoring and reporting tools. The list is large.
For software in the first category, jealously guarding that code makes commercial sense, but the situation is different for software in the second category.
In-house developed, commodity or infrastructure software of itself offers no commercial advantage. It is software that is needed as part of the overall operations and may indeed handle a significant part of the 'heavy lifting' for a project, but it does not form part of the competitive edge of an organisation. It is not this commodity software that plays a role in differentiating one organisation from another.
Software development (and its long term maintenance) is an expensive activity, so if a way can be found to reduce the cost of creating and maintaining this commodity software, it is very much in an organisation's best interests to grab that opportunity with both hands.
For both sorts of in-house developed software, software development costs are the significant up front costs. Over the life of software, it is the maintenance costs that generally dominate. Open source offers the possibility of significantly reducing both the initial development and long term maintenance costs of commodity in-house software.
The first area in which open source can provide significant assistance to in-house development is through the use of open source software development tools.
In the server environment, open source compilers and the supporting tool chain provide the cheapest cross platform development environment available (including Microsoft platforms), whilst providing very high quality systems.
By basing server development work on tools that are available across a very wide range of platforms, a number of significant benefits can be achieved:-
Vendor lock-in is avoided, ensuring that the in-house investment in development is neither orphaned nor held to ransom by changes in availability, pricing or licensing by vendors.
Software development tool costs are minimised - and more importantly, source code for these is available. This ensures in-house development time lines cannnot be hijacked by compiler and tool chain bugs that a vendor takes too much time to fix.
Software development is unshackled from reliance on expensive hardware. As the exact same open source software development tools are widely available across all Unix, Linux and many other operating systems (irrespective of vendor), expensive RISC workstations can be replaced by cheap Intel hardware for software development work.
Coopetition is a word coined by Adam Brandenburger of the Harvard Business School and Barry Nalebuff of the Yale School of Management to describe the tactic of using a judicious mixture of competition and cooperation in a business environment. For some activities, it may be of benefit to cooperate with another organisation, whilst at the same time competing in other activities with the same organisation.
Using open source licensing for commodity software in cooperation with competitors whilst carefully guarding software that provides a business edge from those same competitors is a classic example of coopetition.
By identifying and placing in-house commodity software under an open source license, significant cost savings can accrue as the software is picked up and used by other organisations. These organisations will not only use the software, but it is also actively in their interests to be involved in its on-going maintenance.
The benefits to all participants in such open source projects are:-
by sharing with other organisations the software maintenance costs (bug and security fixes, ports to new operating environments, addition of new features, performance enhancements etc), these costs are reduced to each individual organisation.
if the commodity parts of a project are identified before development starts, it is possible to leverage the open source development model from the outset, sharing the initial development costs with others who also need the functionality.
As an organisation's competitors operate in the same arena, it is probable that these competitors will end up cooperating in open source development: hence coopetition; after all, they face many of the same business realities, opportunities and constraints. The coopetitors in such projects will also probably discover that there are many other potential uses of the software beyond the specialist field in which it started. This serendipity is a common occurrence with open source projects and the added insight from disparate fields can significantly increase the downstream benefits of placing a project into the open source domain.
Open source can provide one further significant benefit. A common problem found in many, many software development projects is the 'not invented here' (NIH) syndrome - a belief that if the entire project is not written in-house, it will result in a less than perfect end product. NIH results in significant, unnecessary expenditure on in-house development.
Organisations that are actively involved in open source are, through their participation in open source, well aware of the value of external resources and hence inoculated against NIH.
Coopetition through the placing of in-house development projects into the open source domain sounds fine in principle - but there are probably a host of issues for newcomers to open source. Probably the two most burning issues are:-
How to determine if each part of the in-house developed software is commodity or competitive edge.
Proof, through examples, that this is not just smoke and mirrors, but solid reality
Rather than dive straight into the first issue (which is of course the big one), it is useful to consider a couple of examples of open source coopetition as they also illuminate that first issue in interesting ways.
Back in 1995, the most widely used web server was the NCSA http server
developed by Rob McCool and released as open source. Unfortunately, following
Rob's departure from NCSA in mid 1994, this software was no longer being
actively maintained. Many web masters had
developed patches and extensions to this software and some of these
were incompatible with one another.
A group of NCSA http server users got together via email in early 1995
and formed the Apache group to take over the maintenance and development
of this software. Using the NCSA software as a base, they integrated the
bug fixes and extensions and the Apache web server was
born.
Within a year, the Apache web server had passed the NCSA web server to become the most widely used web server on the Internet - a position it still holds by a wide margin.
Along the way, the open source Apache server has made its way as a component into a wide range of commercial products - such as IBM WebSphere - and most of the companies using Apache this way have staff members who have been invited to join the Apache Software Foundation (for a list, see http://www.apache.org/foundation/members.html ).
The critically important point here is the reason Apache came to be: contributors to the Apache open source project realised that whilst they were (and remain) competitors, they were not competing in creating a web server, but competing in terms of offering web content by using the web server. Even organisations like IBM, which were basing commercial products around a web server realised that the web server itself was a commodity. Where they were competing with other ecommerce suites was not at the web server level, but in the additional software integrated into the package to create a complete ecommerce suite.
The web server itself is thus commodity software to all participants and it is actively in their interests to collaborate on the maintenance and on-going development of this, gaining the advantages and benefits already outlined.
Digital Creations (now Zope) in the USA had written and was using with its customer base a web applications server called Principia. It deployed this software when working with customers to develop rich, interactive web sites with intelligent web based applications.
In 1998, Digital Creations sought external investment and as part of that process was required by the investors to look at and clearly define its core business. This investigation lead to the realisation that their core competency was delivering specialist web design services and consultancy rather than writing software.
Principia was therefore commodity software rather than part of their competitive edge. Accordingly, Principia was made open source as the Zope web application server. Zope is now widely used around the world and has an active developer community, all of whom use this commodity software as part of their business.
In the case of Zope, the key issue to understand is that it was an examination of the core competency and business differentiators of Digital Creations that lead to the realisation that this in-house software was commodity software and not a part of their competitive edge (or even a potential spin off as a commercial product).
By placing Zope in the open source domain, Digital Creations ensured that it would continue to have access to this software on which it built customer sites, but at much reduced cost (through the shared maintenance benefit of open source). It would also gain the benefits of having others contribute features, functionality and bug fixes to the software.
As the software was owned by Digital Creations, one possibility that they had was to commercialise the software, either themselves or by licensing it to a software vendor. Whilst commercialising the software would potentially provide revenue to the company, it was felt that more revenue could be made by using the software with customers and reducing the development and maintenance costs by making it open source.
At the time this decision was made, there were already a number of commercial web application servers available. Digital Creations used their own software as they felt it gave them and their clients increased flexibility and was better suited to their needs. This does not however guarantee a commercial success for the software in the face of well established competitors.
The decision to go the open source route is thus not as surprising as it first seems.
When considering in-house developed software for potential open source action, this is the critical decision. The factors determining this will vary significantly from organisation to organisation. Much will depend on a clear understanding of the organisation's core competencies and its mechanisms of business differentiation from its competitors.
In terms of opening up internal discussion, an interesting approach is to ask "Why is this particular in-house software not suitable as an open source target?" rather than to ask "What software can we make open source?". Asking the question in the former way requires people to start to consider things from a potentially open source perspective rather from their accustomed standpoint.
One interesting result of examining in-house development this way is that
it requires that the existing open source software in the fields under
consideration be reviewed. This can lead to a realisation that there is
already an open source package available that can be used to replace some
of the in-house development. It may be that some work may be required to
fully integrate this - but this work can be contributed to the open source
software development effort.This can result in
significant and quite rapid savings.
It is also important to choose the right open source licence. There are a wide range of open source licences that differ in the rights and freedoms they provide you, other contributors to the code and other users of the software.
Although all such licences have much in common, the devil is, as always, in the detail. It is strongly recommended to seek advice (from both experts in open source and software licencing) before making a choice.
Open source offers significant potential for the reduction of costs for in-house development. Achieving these savings does however require that an organisation understand open source and how to operate in a very different development environment. This difference is there even if the organisation is simply using open source software, rather than contributing to (let alone leading) an open source development effort.
Making software open source is a process not an event and requires particular attention by and skills from an organisation if it is to be successful. Simply 'throwing code over the wall' will not guarantee that it attracts other developers and become a vibrant open source development effort.
Fortunately, given the prevalence of open source software, it is quite likely that your in-house developers are already using open source software in-house and thus there is already knowledge and experience available inside your organisation to build upon, possibly with some external assistance.
More information on Apache and its history is at http://www.apache.org
More information on Zope (the software) is at http://www.zope.org and Zope (the company) at http://www.zope.com .
More information on the various open source licences is at http://www.opensource.org/licenses/index.html . This site also has some useful information about open source (including one definition of what open source is, although this is still much debated in the open source community).
This clearly demonstrates the difference between the code and the domain knowledge and is at the heart of any decision to shift source code into the open source domain.Source code control is at the root of their product control; letting other people use any part of their code is so self-evidently absurd they think I'm not serious. But I am. The various public licenses boil down to fairness -- they don't require that all intellectual property be made public, but if you use open source, I tell them, you should be prepared to put something back. The real bottom-line is that their future success with Impress doesn't depend on source code control anyway. It's domain knowledge and customer relationships that matter. Right here and now, however, they're a tough crowd and I'm not pushing it. In the long run this is the way most small developers are going to have to go.