Introduction In the rapidly changing IT industry there are certain applications that an organisation may be interested in developing while there is no suitable commercially products available. Time and time again, individual organisations effectively re-create the wheel internally funding small projects to fulfill business needs. When embarking on an internal project typically the requirements are not well defined, this result in a system which fulfills short term goals and then generally has to be re-engineered as these goals change and the long term goals are realised. Some internally funded projects are common among a number of organisations. Through making the non-business specific portions of the project generic, a number of projects can be enhanced to the point where multiple organisations can use the same core and customise it to fulfill their business needs. These core parts of the project can be Open Sourced[1]. Of course some projects will never be suitable for becoming a collaborative Open Source project. They are simply far too entrenched in the business process of the organisation. ------------------------------------------------------------------------ The Three Basic Options When faced with a business need, historically there are generally two options. These are Buy it or Make it. With the mainstream acceptance of Open Source software there is now a third option Collaborate. Buy it This involves purchasing a Commercial Off The Shelf (COTS) program and then enhancing it to suit the business need. For example, a common group-ware application such as Lotus Notes can be purchased and then developed to provide customised work flow applications to suit a business need. Make it This effectively involves a complete application development process to create the system that fulfills the organisational needs. In todays IT industry these typically are web applications. Alternatively an organisation may develop a system where they are intending to use the system as a delivery mechanism for information that they have complete ownership of. Collaborate This involves working with a group of developers from various organisations building enhancements to a product to suit the organisations needs. Feeding, where appropriate, enhancements to the core portions of the product back into the development community. Depending on the particular system it may be beneficial to create a working core subset of the system and then allow other organisations to access the code, allowing them to enhance and feedback any improvements. Likewise it might be useful taking an existing Open Source product and work with the developers to improve portions of the system that help fulfill the business need. ------------------------------------------------------------------------ The Business Case Funding Primarily Business Needs Only Ideally an organisation should be able to fund only the portions of the project that has some direct time or monetary benefit to the organisation. This is only achieved where the portions of the project that directly relate to the business needs are being developed or maintained. The core parts of the system are maintained by multiple parties. In some cases the business needs reflect a proprietary or private aspect of an organisation. The nature of these needs may result in a Competitive Edge for the organisation and consequently may be considered an organisations Intellectual Property. In such cases it may be prudent to maintain the proprietary nature and keep the implementation around that business need internally managed. Sharing The Cost of the Core When a small project begins (usually from scratch) a competent developer spends considerable time developing the core functionality of the system. This time spent developing the core is at the expense of fulfilling the business needs. Although the core is a necessity for the business needs to be fulfilled, if there is commonality amongst other organisations, the effort needed to build, debug and enhance the core can be shared. Investing in the Future When a Commercial Off The Shelf (COTS) system is purchased there is a reliance on the original vendor to continue supporting the product. Since a proprietary product generally comes in binary format only, it is very difficult for an organisation to maintain its investment in a system when it can only be treated as a shrink-wrapped application. Even if a vendor does continue supporting a product, extra features usually become available only through sometimes costly maintenance contracts or software upgrades. With Open Source software the investment in the development and management of the system can stay for as long as there are organisations using and enhancing the product. If an organisation still has compelling reasons to stay with the system, they can maintain and enhance it for however long the business need dictates. If the community development of the system wanes due to lack of interest by other organisations, then an organisation can pick up the management of the system and possibly give it a new lease on life. Information is the Key Many applications are developed to provide the information to an end customer or user. The customer may not necessarily care in what form the information comes. They may only care that they can use it. With systems where the provision of information is more important to the organisation than the mechanism itself then an examination of the mode of development could be useful, particularly when other similar organisations that have similar delivery needs may also be willing to share the burden. Continued Development When an internal project completes, development generally halts. The system developers move into bug-fix/maintenance mode, adding very few new features. With a successful Open Source project development will continue as long as there are participating organisations around that will need enhancements to the core portions of the system to assist them fulfilling their business needs. This is similar to COTS products where the new features are added and are expected as part of the regular upgrade cycle. Due to the tight feedback loop within the Open Source model, the features that are added to the system are generally what is required by the users. This contrasts strongly with the COTS situation where enhancements made to a product are controlled by factors which aren't necessarily apparent to the end user. More Support Options With an Open Source project anyone is as capable as the next person at supporting the product. All portions of the system are completely visible. If a real fix is needed it can be done either internally or externally. This can be contrasted against both an internal project and a COTS product. The internal project will have only a few people who are knowledgeable about the internal workings of a system, outside of the organisation there will be fewer. Hence a fix can only come from this small group of people. With a COTS product the only source of a fix can be a single vendor, where they decide if the fix is advantageous for them to implement. Lower Purchase Costs Due to the freely distributable nature of Open Source products a side effect is that generally the software has a low (or no) purchase price. Consequently upgrades of the software are likewise low cost. ------------------------------------------------------------------------ How to do it Borrowing heavily from Eric Raymond's The Cathedral and the Bazaar and Home-steading the Noosphere [2], there are some pre-requisites that are generally accepted as being needed to successfully organise an Open Source project. These rules apply equally to an individual heading a project as to an organisation. Most of these pre-requisites will tend to feed and enhance the others. Depending on the precise nature of the project some of these may be less or more important. Build the Base No one will look at re-using/contributing development to a system that has no direction. For a system to be taken on by multiple parties the skeleton of the system should be sufficiently advanced such that an organisation can see that the system can be extended and used to serve their business needs, whilst at the same time extending the skeleton and re-contributing the improvements back to the core. Lower the entry cost Even if the base has been built, ensure that the design and development has clear indications about where to go to solve a problem. Jamie Zawinski, a past employee of Netscape Communications made some points on this in a post-mortem of his resignation in 1999[3]. Although he offers them as possible excuses for (in his opinion) the failure of Mozilla to deliver, they are still valid and should be taken note of when releasing an existing code base. Drop the Ego Drop the politics too. Open Source projects rely on the free exchange of ideas and information. Project leads that have too high a belief in how they are achieving a technical goal and ignore others can be very bad for the project. Each solution should be weighed according to its own merit, not based solely on what the project leads feel they want to do. There truly are many ways to skin such a technological cat. Work the Culture, Build the Community The Open Source community is a gift culture. Your standing within the community is related to how much you give to the community, and the quality of that gift. Creating a tight loop within the community is a very important part of an Open Source project. Encouraging involvement in all areas of the feedback, development and testing process assists in the building of a mini-community around the project. Facilities such as mailing lists, active web sites, IRC and discussion groups all assist in getting the community involved. If developers feel they are valued they will stay involved. Commercial Opportunities Even though the Open Source community is a gift culture, there is nothing stopping any organisation making money out of Open Source software. Many organisations have made considerable money from commercialising Open Source products while at the same time remaining part of the community. It must be understood that although there are commercial opportunities for Open Source products the footing is very even. In terms of intellectual property rights, there is no-one who has trade secrets that gives them a competitive edge. Successful commercialisation may depend on known activity, accepted knowledge or value being added to an Open Source product. An example could be IBM's use of the Apache web server, where it is generating an association with Apache through the assistance of porting Apache to a number of other platforms, thereby creating the association and value-adding. Realms of Activity Projects in the Open Source community sometimes fork or equivalent projects are started. Each similar project wastes effort. Each project has its own realm that it responds to requirements within. Apache is web services, Samba is SMB services. If there is an Open Source project that can be enhanced to fulfill the business requirement, use that project and enhance that. Just like duplicated effort within a single organisation is frowned upon, in the Open Source community it is treated the same. If there is no equivalent project or there are sufficient differences from an existing project, stake out claim in that realm and limit activity to that realm. There is room for multiple smaller projects that are more specialised fulfilling the same realm of activity. If the requirements that the project is fulfilling become large enough the smaller projects will begin to wane or get absorbed into the larger project. Drop the Ownership Issues With an Open Source project there is no 'it's our project, we can do what we like'. If a project is successful it becomes a community asset. The level of executive control over the code for a project varies depending on what particular license it is placed under. A well run Open Source project maintains a firm belief that the Community owns the code. Without this the project begins to garner the appearance that the project leads are using the community to gain a commercial advantage, which fragments and discourages involvement. ------------------------------------------------------------------------ Negative Aspects The picture is not all rosy however. There are some real issues that need to be understood and accepted at the corporate level. These concerns are addressed and presented in an appropriate light. Non-contributing Users These are people who may use the system as developed but don't actively contribute to the development/enhancement of the product. Although on the surface this appears to disadvantage an organisation leading the project, it is an aspect of the community. There are active developers, active debuggers, bug reporters and users. The non-contributing users are a just a component of the community. In fact the bigger the non-contributing community the bigger the other community sectors will be and consequently the more successful the project will be. Funding other Organisations With Open Source development, organisations who fund the project also fund the use of the system in other organisations. This should not really be a concern since in most cases the development would have occurred anyway and the other benefits of Open Source development model may not have been realised. Once Free, always Free Once a decision has been made to move to an Open Source model, the license that the software is placed under will usually require that the software can only be moved out of the Open Source environment if all copyright holders agree. The copyright holders are generally all authors of the code. This generally includes patch contributors and core developers. The decision to go Open Source is not to be taken lightly. People Can Make Money People can make money out of Open Source products. Depending on the form of the license placed on the software, the methods that an external organisation can make money can be controlled. There will always be opportunities for the commercial provision of support and management of an implementation. If anything this sort of behaviour should be encouraged, since it increases the mission-critical status of the project and increases user, development and bug finding market. Any organisation within the community has the same ability to make a commercial profit out of a project. No Guarantees Unfortunately there are no guarantees that the community will rally around an Open Source project. Depending on the attitude towards the adoption of the Open Sourcing, it may not be a loss if it is considered that generally the same effort would have been needed if the application had not been Open Sourced and developed internally by the same developers. Not the Domininant Platform Due to the history of the Open Source movement, the community tends to be more comfortable with the Unix environment. There is definitely a larger amount of Open Source development occurring within the Unix environment than on the Microsoft Windows platform. Fortunately if the effort is made to port to a different platform, the community tends to be very careful that enhancements encompass as many of the ported platforms as possible. ------------------------------------------------------------------------ Examples of the Model Large corporations are investing money into the model. They can see the benefits of the model when applied to even their flagship products. IBM Web Server IBM have selected Apache[4] as the webserver that is going to act as the core of their web strategy. Now IBM are concentrating on development of their value added products such as WebSphere which run on the Open Source Apache core. IBM is also working with The Apache Group to port Apache to the AS/390. Netscape's Mozilla Netscape released what was their core browser, Mozilla, to the Open Source community. Netscape still keep the browser branding, but get the benefits of the Open Source community continuing development of Netscape Navigator. Netscape have stated their main interests lie in their NetCenter Portal and corporate products. And so even by association with the Open Source browser they will gain mind-share in the Web Services market. Corel's Windows Suites Corel has been eyeing off the Linux market as an alternative to the Windows market. Corel has agreed to assist with the development of wine[5], to reduce the effort required to move some of their windows platform applications to the Linux market. Further to this Corel has also built products around Linux (an Open Source operating system) such as the NetWinder network terminal. ------------------------------------------------------------------------ Conclusions There are real benefits to an organisation that takes on the Open Source model, especially when compared to the similar effort that would have been needed to undertake an internally funded project. Once the step has been made to go Open Source the most difficult decision has already been made. If a project is successful, an organisation can commercialise the delivery and support of the product and still remain a contributor within the Open Source community. ------------------------------------------------------------------------ References [1] Bruce Perens; The Open Source Definition; http://www.opensource.org/osd.html [2] Eric Raymond; Eric's Random Writings; http://www.tuxedo.org/~esr/writings/ [3] Jamie Zawinski ; nomo zilla or, resignation and postmortem; http://www.jwz.org/gruntle/nomo.html [4] Apache Web Server Home Page; http://www.apache.org/ [5] Wine Headquarters; http://www.winehq.com/ ------------------------------------------------------------------------ Acknowledgments I would like to thank the following people (in alphabetical order) who have assisted me with the development of this paper. Tom Mittiga; DEHAA; Initial request for discussion paper on issues regard open sourcing existing projects. -- Matthew Tippett - +61 416 006 047 - mtippett@ticons.com.au Linux Support Initiative - BETA Testers Wanted - http://lsi.ticons.com.au/ Tippett Information Consulting Pty Ltd - - http://www.ticons.com.au/