Sun Microsystems Inc. is a US company that was founded in 1982 by three students of Stanford University (Scott McNealy, Andy Bechtolsheim and Vinod Khosla) and one student from the University of Berkeley (Bill Joy).

The main purpose of the company was to design microprocessors and workstations for the University of Stanford, which is why the company was named Sun (after the Stanford University Network). From the outset, the founders were aware of the importance of using open standards to develop their products, which is why they chose to design their microprocessors using the SPARC standard. They also chose an operating system based on an open standard, Unix, to act as the driving force behind the systems they designed. In doing so, they had a great advantage because Bill Joy had developed Berkeley's Unix operating system (BSD) some years earlier.

Since 1982, the company has continued to grow and it markets its systems in virtually every country of the world. Sun's designs have also been adapted to market needs, which has seen the sale of workstations evolve into a wide range of servers and multiprocessor systems.

Sun Microsystems was and still is an innovative company that, as we will show, has always maintained a close relationship with communities that support open standards. Proof of this are the many technological contributions made to these communities by Sun.

Sun Microsystems has commercial offices in over 170 countries around the world, which means that it needs a wide area network to offer top communications and services to its 35,000 plus employees. This network is referred to as SWAN (Sun Wide Area Network) and consists of over 6,800 subnetworks with 6 data processing centres (DPCs) that house the over 1,700 servers and 500 TB of data. The number of subnetworks, servers and storage systems increases as needs grow. To cite some key figures, Sun servers currently host over 400 network applications and 18,000 websites of over 4 million pages that receive 600,000 visits and move over 6 million e-mail messages every day.

Sun has over 3,500 engineers working on the research and development of innovative new technologies that could help businesses and end users to cut the cost of implementing new network services. The free software community is one of the groups that most benefits from the investments in research and development made year upon year by Sun, since most of these technologies are donated to the community to ensure its continuous evolution.

A prime example of the sizeable R&D investments made each year by Sun are the USD 1.9 million allocated to this heading, which represents approximately 18% of the company's turnover. The more than 3,500 registered patents are the result of these efforts.

The private sector's main concern when it comes to software is how to innovate efficiently. Innovation is straightforward and relatively common and yet, predicting which of the products being developed in R&D laboratories will have an impact on the market and generate profits for the company is no easy task.

Innovation expenditure can be very high for a company if it cannot obtain an efficient return on its products. This is one of the main reasons why the private sector has been paying more attention to the free software community in recent years. The amount of money that a company can afford to pay for top engineers is irrelevant; it needs to realise that no matter how brilliant the company's development team is, there will always be others who can innovate more efficiently. So the old expression "innovation is all around us" rings true here; we just need to find the mechanisms to profit from it.

There are a number of reasons why a private sector company might decide to launch a free software project. Here are a few of the main ones:

When a multinational launches a free software project, it contributes experts and a series of procedures and processes that do not generally match the way the developers of this community work. Its main contributions are:

The company must still use the project launch and management paradigm that it usually uses because this is the only way to control expenditure and project time, thus avoiding delays and unforeseen expenses that could lead to failure.

On many occasions, the costs of a project based on free software are higher than those that use a proprietary software approach.

One of the key points to bear in mind is the model adopted for licensing the free software applications. One of the myths surrounding free software is that it is not owned by anybody and that when a company develops a free software product, it must forego its rights and control over ownership. There can be nothing further from the truth: the free software model recognises ownership and its concomitant rights.

Companies need to think carefully and consider whether there is any point to launching a project linked to the free software community; in other words, it will need to study whether the code adapts to the needs of the company, whether the licences suit the deployment model that the company wishes to adopt, etc. Following this preliminary study, the company will no doubt need to adapt the source code, choose the licence model, establish a development model, draw up a cost study for launch, etc. We will deal with all of these points later.

Earlier, we listed some of the reasons why a company might opt for a free software project. We will now look at some of these in detail:

Feedback

Private businesses can use the free software model as a basis for sharing tools, technology and prototypes. However, it is more important to create an ecosystem around the free software in which the company and the community join forces and share common aims in order to strike a perfect balance.

[D]

A prime example of this type of ecosystem is that created by Sun Microsystems with its StarOffice office suite. In version 6 of StarOffice, Sun Microsystems released the source code, which led to the creation of openoffice.org. Developers from the free software community have now evolved this product, adding new features and allowing the ecosystem to operate just as we have described.

The community developers add new features and Sun subsequently markets the new version of the product after extensive quality testing, with an additional user support service.

Creation of an appropriate development plan

When a private sector company embarks on a free software project, regardless of the purpose of the end product, it is going to need a coherent development plan that adapts to the company's standards and allows deadlines to be met.

It is important to consider that a project developed entirely by the private sector will be subject to a series of working methodologies and procedures that products developed by the free software community do not have. Therefore, both parties (the company and the free software developer group or community) must be clear on the parameters and paradigm used in the development cycle of the end product, since the two products need to be connected throughout the cycle in order to avoid incompatibilities. There are a number of models for linking the two versions:

• One involves basing the brand version on a stable version of the free software application. In this model, any changes to the commercial product flow in the direction of the code of the free software application. This process ensures that the two codes are compatible and that they have the greatest possible number of similarities in order to minimise version problems. The development plan requires the development cycle of the commercial product to be in step with the cycle of the free software application.

[D]

As we can see, there will not be many differences between the free software version and the commercial version. The latter may have the odd new feature or functionality but most of the parts it has in common with the free software version will be a subset of the official free software version.

• Another, less desirable, development process involves having two code bases and leaving it up to the developers of the private company to decide when to merge theirs with the free software application. This model has an advantage over the previous one in that it gives greater flexibility to the company developers. However, it also has the disadvantage of complicating source code management due to the existence of two bases evolving independently.

[D]

Development of the two products is parallel and there is no relationship between their delivery cycles. The code from one of the projects is simply injected into the other when the developers of the company consider it convenient to do so.

This model has the advantage that the two versions will have different features, since they are essentially two different products with very similar appearances.

• A third development model is as follows:

[D]

In this model, development of the commercial product is internal and not visible to the developer community. When finished, it is shared with the free software developer community. The private sector companies that use this model generally have their own developers working exclusively on the commercial product, leaving the development of the free software to outside volunteers.

This model requires the least contact between the company and the free software developer community. Many companies opt for this model to add their name to the list of companies that promote free software and collaborate with its community. However, these projects usually fade away after the first version because the company no longer collaborates to allow the project to evolve satisfactorily.

Sun Microsystems began the openoffice.org in this way but adopted a different strategy to prevent the free software project from petering out. Its strategy was to combine this development model with the first one we described: after creating the commercial product, the code is released and handed over to the free software developer community (Model 3), after which Model 1 is adopted, allowing both communities to release new versions.

Software life cycle models: SBS PLC

SBS PLC (Sun Business Systems Product Life Cycle) is the standard life cycle model for information technology infrastructure projects and their developments.

Any project developed by Sun Microsystems is subject to the procedures and methodologies set down in this standard. The model may vary according to the type of project, its priority, critical status, etc. Nonetheless, the life cycle of a project is always divided into the same stages:

[D]

Sun Microsystems carries out projects to develop applications for use in its own departments, while others are designed for global use. Hence, it classifies project models according to type, which include:

• Waterfall

• Iterative

• XP

• Micron

Depending on the duration of the project and the time and people required for its development and subsequent deployment, we can draw up the following table to identify the type of model that needs to be used in each case:

We will now look at the aims and potential risks of each of the phases of a project in this life cycle model:

• Diagram phase (pre-concept phase). By creating, reviewing and subsequently approving diagrams, the company can guarantee that the project will have a business case coherent with its strategy and priorities.

  The most obvious business risks in this phase are the possible lack of justification for the project or discrepancies with the company's strategy and priorities.

• Concept phase. This guarantees that the concepts have been reviewed and that there is no better alternative than the one proposed. Approval from the management committee is required to ensure that the project meets the business aims.

  Potential risks may stem from a poor assessment of the alternative products, which could lead to a system being implemented that does not meet the needs of end customers and is hence doomed to failure.

• Planning phase. This ensures that the project meets the architectural requirements and complies with the security conditions, standards and policies of the company. All of these parameters need to be validated before we can move on to the next phase.

  The most obvious risks usually concern a functional, technical and deployment design that is not in tune with company policy and would result in a product veto in the next phase.

• Development and integration phase. This ensures that the product has been correctly developed and integrated and ready to move on to the next phase.

  The only risk associated with this phase is that the product is not ready for the validation phase.

• Validation and product testing phase. This phase ensures that the product has undergone rigorous revision and validation with the sole aim of moving it on to the next phase (customer acceptance). The product validation and testing reports must be submitted to the Management Committee.

  The only risk associated with the product in this phase is that it does not qualify to move on to the next phase.

• Customer acceptance phase. This phase can be seen as a condensed version of the previous phases, since it allows the company to review all of the deliverables obtained in the previous phases and approve the project for launch.

  There are no risks other than the possibility of the product not being ready for the launch phase.

• Launch phase. This ensures that controls and measures are in place for the solution in order to ensure that the product meets the client's needs for the duration of its life cycle.

  The risk associated with the product at this stage is that it may be unsuccessful if any of the previous phases were carried out inadequately.

Process flows for the implementation of a project at Sun Microsystems

Concept phase

[D]

Planning phase

[D]

Development and integration phase

[D]

Validation and product testing phase

[D]

Client acceptance phase

[D]

Launch phase

[D]

Sun Microsystems has adopted a clear stance with regard to the creation and evolution of software. From the outset, the company has always encouraged the development of hardware and software products based on open standards, with a view to fostering free competition through the publication of protocols and interfaces so that other companies working in software creation can compete freely.

Sun considers it necessary to support the free software community by contributing source code and human and financial resources to allow the community to improve or adapt these programs and for Sun Microsystems to subsequently launch them on the market with a series of added services, such as support, training, etc.

After releasing the code of Solaris 10, Sun Microsystems became the number one organisation for lines donated to the free software community, ahead of the University of Berkeley.

When Sun Microsystems decided to launch a workstation system based on free software technology, it did so with a series of conditions:

The project, known internally as "Mad Hatter", would thus have two types of client: on the one hand, the employees of the company and, on the other, users and companies. Although this case study will deal primarily with the first case, i.e. the launch of a desktop system known externally as the Java Desktop System within Sun Microsystems, the phases prior to distribution of the product were exactly the same, regardless of the end client of the product.

Market needs and study

The first step before deciding on the applications that would form part of the project was to pinpoint the needs of the market and the associated risks and benefits. After identifying these, they had to be guaranteed to fit in with Sun's strategy.

The product had to meet the following aims in order to meet market needs:

• To provide a series of applications based on open standards that were integrated and would provide an interoperable, secure and well-defined working environment.

• To guarantee a working environment for users that would make them feel comfortable and be familiar to them.

• To use pieces of free software code to avoid being bound to a single technology.

The desired workstation features for clients were:

• An open and cheap workstation allowing them to be set free from the bonds of proprietary technologies.

• An elegant design that was easy to handle and manage.

• A working environment that could let them rest easy about computer viruses.

After analysing the market needs, Sun had to determine which applications would form part of the new workstation:

Given that Sun's main aim was to gear the product towards professionals, it had to be clear on the fact that employee needs and uses of workstations are very different to those of users in non-professional environments.

• An environment in which to run applications.

• An e-mail client, directory and calendar.

• A browser for visiting Intranet/Internet sites.

• An office automation suite for giving presentations and producing text documents, spreadsheets, etc.

• An intuitive graphical environment to run the above applications and other less important ones that had to be included nonetheless.

• All applications had to run on any of the Sun Microsystems operating systems:

  • Solaris (SPARC architecture)

  • Solaris (x86 architecture)

  • Linux (x86 architecture)

The first version of the Java Desktop System (JDS) workstation had the following components:

Study of the Java Desktop System (JDS) applications

Before describing each of the applications in detail, we ought to think about the value of Sun's idea of offering a workstation such as Java Desktop System based on open software:

• The appearance of the graphical environment had to be as similar as possible to Windows operating environments because this is the most commonly used PC platform in the world.

  The GNOME desktop environment has a series of menus and icons to allow as smooth a transition as possible.

Many business users are not advanced users of IT systems, so the main aim was to avoid rejection by this group.

• Device management had to be straightforward. It is often necessary to connect the workstation to an external device (scanner, printer, etc.) and this operation should not cause problems for users.

• The workstation had to be integrable and interoperable and not limited to a specific type of application. Therefore, it had to be based on open standards, as this would allow its integration with existing technologies in any business environment (directory servers, e-mail, databases, applications based on the Windows operating system, etc).

GNOME graphical environment	Description and features
Figure 1	GNOME is most popular desktop environment in the free software community. It has a familiar operating system management appearance with menus, icons, file management, accessories, system tools and a range of customisable screens that provide a comfortable environment for the end user to move around in.

The appearance of the working environment with GNOME looks like this:

One tool that is a must in professional working environments is an office suite. The tool with the biggest market impact at the moment is Microsoft Office, which is why Sun Microsystems has invested considerable human and financial resources in producing a market alternative that matches its features and guarantees 99% compatibility.

StarOffice office productivity suite	Description and features
Figure 2	Ease of use. Anybody who has used MS Office is able to work with the StarOffice tool with no further training. Interoperable. It can export any type of document to a variety of formats, including PDF, Flash XML, .doc, .xls, .ppt, .rtf, .psw., etc. Open format. It works with files with an internal format based on XML.

The tool looks like this:

Ximian e-mail client	Description and features
Figure 3	E-mail client, directory, calendar, etc. It supports the most common e-mail protocols and can be integrated with a calendar server. It is very similar in appearance to the MS Outlook client.

You can see what Ximian Evolution looks like in this screenshot:

Mozilla browser	Description and features
Figure 4	Browser that supports the HTML, XML and CCS standards, among others. It includes an HTML editor, download manager and a wide range of advanced features. It is installed with pre-configured plug-ins for Java, Macromedia Flash, Adobe Acrobat Reader, RealPlayer, etc.

The appearance of this browser is as follows:

There are many other applications that come with the ones described here but they are not included in this study because, while useful, they are not essential to the day-to-day running of a business.

Control metrics used by the IT operations department

One of the most significant processes of the design and subsequent implementation of a free software system at Sun are metrics, which help to predict the guarantees of success of a product.

There are many metrics for estimating costs, risks, quality, efficiency, etc., studied by the Head of Operations for the geographical region in which the system is to be implemented.

The key data managed in these metrics are those concerning the staff available to implement the applications correctly. They include the ratio of end users to the number of engineers occupied with these tasks.

The Sun Microsystems IT Operations Department has a total of 265 staff administrating and installing corporate applications on over 1,810 servers, which serve the 35,000 plus employees. To put it another way, each system's administrator is responsible for managing and monitoring more than 135 workstations.

Another interesting metric is that concerning quality and productivity: Sun Sigma methodology. Sun Sigma is an adaptation of Sun's Six Sigma methodology, which is basically a scientific method for improving processes, products and services. All decisions on the introduction of improvements are based on data collected from the various departments.

These metrics can be used to pinpoint the areas in which processes can be improved in order to help to cut costs.

ORI ( Operational Risk Index ) is an index obtained by analysing the environment of Sun's systems in production. It analyses the systems and studies their risks, classifying them according to status (low, moderate, high and critical). Once we have the values for each system, we can then obtain their risk of failure.

[D]

The formula for obtaining a department's ORI is:

(10*critical) + (5*high) + (3*moderate) + (1*low) = ORI

After analysing a system in production with a tool called Explorer, the results are compared to the values that Sun Microsystems believes the system should have in an ideal environment. Risks are classified by criticalness using the above formula.

A system has been evaluated and the following results have been obtained:

Risk level	Number of potential problems
Critical (critical)	2
High (high)	5
Moderate (moderate)	8
Low (low)	10

The ORI of this system would be 79.

(10*2) + (5*5) + (3*8) + (1*10)=79

Finally, it is important to obtain metrics for the efficiency of the workstation, local network services and wide area network services.

The figure below illustrates an example of the cost savings obtained by Sun through workstation efficiency:

When the product is ready to be installed on all file servers and SWAN network applications, the company needs to adopt a global approach to its deployment that will allow the software currently installed on the systems to be replaced with the new product. Deployment management allows the diverse groups responsible for hardware or software to coordinate implementation of the new system in an environment of centralised servers located in different countries around the world.

The responsibilities associated with this management can be summarised as follows:

On occasion, installation affects a specific group of company applications that can be treated as a single group while at other times deployment only involves upgrading the version of an application. Hence, there are several types of launch, each depending on the nature of the components to be installed:

The corporate software database contains the master copies of all software controlled in the company (both purchased programs and software developed in the R&D laboratories). The exact configuration of this database must be defined and revised before any launch.

The software components included in a new installation should be assembled under controlled conditions to ensure a reproducible process. It is quite common to automate this process to reduce dependence on human involvement, thus increasing reliability. Sun Microsystems has developed an entire systems and processes architecture called N1, by which this process can be carried out with minimal human intervention.

The launch must undergo rigorous testing and obtain user acceptance. Due to the high number of end users in a multinational like Sun, a small group of users (with different technical profiles) is selected to pass and validate the tests for global launch. Sometimes, despite completing each of the steps described in the launch procedures, a software version can generate a run error or prevent the installation from working correctly. In this case, we need a backtrack plan that documents the steps to take after a launch fault.

Launch management

A centralised launch management like the one described has countless advantages over a non-centralised one:

• The installations are carried out on a limited number of servers, which means that the database of registered equipment is not too large.

• The time spent on the last phase of the launch is reduced to a few minutes.

• The performance of backtracking procedures and reinstallation of the previous software is also a matter of minutes.

This is very useful when an error occurs or a fault is generated in one of the installed applications.

• Improved quality of service due to more successful installations and a considerable reduction in business downtime, which is zero in most cases.

• It ensures that the installation remains in the hands of professionals who specialise in this type of management: the end user will never have to perform operations with the installed software.

• Improved use of resources.

Distribution tools

The IT Operations Department of Sun Microsystems uses a procedure called SoftDist to distribute the software once it has been launched. The aim of this process is to ensure that the central servers in each of the regions have the latest version of the software that the company wishes its employees to use.

Before moving on to the steps for distribution of this software, we need to be familiar with the following terms:

• Submitter: Sun Microsystems employee in charge of preparing packages for distribution.

• Package: software application that can be used by any Sun employee inside the company.

Requirements for software distribution

• Identification. All packages for installation must be assigned to a Sun employee before distribution can begin. This employee is usually the Head of the Operations Department for the region. The information required is:

  • Name of the individual or department group.

  • Identification and supply of the resources needed to deal with any problem with the application, regardless of whether the questions concern the end of the product's life, support, bugs or maintenance.

  • Identification of the contact person for any product support issues.

• Approval. All packages for installation must be approved by the Head of the Operations Department for the corresponding region, which guarantees functionality of the application and coordination of compatibility with other products, databases and applications relevant to the business aims. The Head of Operations must be perfectly aware of the company's aims, the risk of a fault in the product launch and the product requirements in order to determine departmental resources needed to make the distribution a success.

Product distribution requirements

• Use of preptool. This tool, exclusively for Sun Microsystems' internal use, allows us to combine and organise the data needed to prepare a package for distribution. All of the relevant information must be entered to ensure operability of the package across the company.

• Export control. Since Sun Microsystems is a US company with offices in different countries, the product must meet the import/export regulations of each country. These regulations are described in Sun's export control department ( Sun International Trade Services ).

  The SoftDist distribution hierarchy and the network topology allow software packages to be distributed to all Sun offices around the world, even in countries where trade with the US is restricted, thanks to agreements with their governments.

  The products developed at Sun Microsystems R&D centres in countries other than the United States must also abide by the regulations of the International Trade Services department.

• Contact with the Product Support Centre. The Head of the Operations Department must contact the Head of the Support Centre as part of the pre-distribution preparations for the package in order to define the product support mechanisms and the support resources and contact person.

Verification of package functionality during distribution

• Functional testing. The Head of Operations must ensure that the packages for installation will not compromise the productivity or functionality of other applications and that they will not affect business operation from the point of view of systems performance.

  The packages for distribution must run correctly on the two operating systems supported by Sun: Solaris and GNU/Linux.

  As explained earlier, the packages must be validated in a simulated environment before global distribution. The package proprietor is responsible for setting the criteria to determine whether the package is suitable for distribution; in most cases, this figure is the person responsible for development of the product or the Head of IT Operations.

• Management of application faults. The Sun IT Operations Department, acting under the head of this department, must provide global network users with a guarantee period and respond to any issues raised during this period, which begins on distribution of the package. Risk situations are processed differently from the standard procedure.

  If a bug has not been detected in the application for distribution and it appears within the first week of distribution, the Operations Department must assume any expenses arising from this moment on. This same procedure is applied when the distributed package has a severe impact on Sun systems performance, causing delays that affect normal activity or prevent users from opening other applications from their workstations. The criteria for determining whether a package has been distributed correctly are as follows:

  • Users must be able to launch the application from their workstations without administrator intervention.

  • The application cannot access areas that the user launching it does not have permission to access.

  After distribution of the software, the Head of IT Operations for each region must obtain metrics of its results by auditing the installations and reporting any unsuccessful cases, detailing the reasons for them and the plan of action to be put in place.

Installations have a quarterly review, at which the support group covers issues detected after the first week of installation.

Other metrics that need to be taken into account by Sun's Operations Department are DPMO (Defects Per Million Opportunities), which attempts to reflect the final result of the quarterly software distributions.

We have already explained that the IT Operations Department is responsible for the correct performance of applications (both free and proprietary software) at Sun. However, any problems detected in distributed packages, whether in design or development, are the responsibility of the product development group.

Any detected bugs can be fixed during the product maintenance phase but it is often the case that a bug found in a package can have a direct impact on a systems performance, and hence on the day-to-day activity of the company. To avoid these problems, there is a standard procedure for assigning a higher priority to the JDS code review, allowing the engineers in charge of product maintenance to solve it as soon as possible.

When a bug is found in a package or application, it is usually reported to the Operations Department, which must then contact the product support team. To do so, Sun has created a bug reporting tool for users to enter information on the type of bug, the part of the application where it occurs, etc.

[D]

The Sun Microsystems Education Department draws up tailored training plans for departments that require special JDS workstation training, offering users intensive courses on the product (user level). This training is only provided if formally requested by the department that needs it, which must also indicate the staff that will attend the courses.

There are different course formats depending on the availability of the employees:

In all events, each department must assume the costs of training its staff.