Script for "How to sell Open Source to Government"

At the recent Open Source Asia/Pacific conference, I presented on the tricky subject of "How to sell Open Source Software to Government", which can equally be read as "What logic can I use to convince my boss that installing Open Source is a good idea?".

The presentation is recorded on this 25 minute video and the script is copied below.

"Selling Open Source to Government"

In 2005 the Australian Government published guidelines describing how to buy Open Source Software.

Despite the potential benefits, however, government uptake of open source is surprisingly low.

Why is that? Well that is what I'll be speaking about today.

• What factors lead to governments favouring proprietary applications?
• What factors drive government purchasing decisions?
• What are the strengths of Open Source?
• How can we ensure that these strengths are recognised by purchasers?
• And how do companies like ours successfully sell Open Source to government, anyway?

Hi, my name is Cameron Shorter, and I'm the GeoSpatial Business Development Manager at LISAsoft.

At LISAsoft we have carved a niche for ourself by being experts in all things GeoSpatial,

• in GeoSpatial Standards,
• in GeoSpatail Open Source,
• in Infrastructure and Hardware,

and we do all this locally, here in Australia and New Zealand, and it is worth noting that being local is an advantage for us Open Source companies.

Like many of our staff at LISAsoft, I've been involved in a number of Open Source projects, and led few of them. Most recently, we have been involved in the collaborative development of a LiveDVD containing 42 preconfigured GeoSpatial Open Source Applications along with associated marketing material, and we have been using this DVD at conferences around the world to promote our Open Source applications.

Now, before we can define a formula for success, we need to understand the challenges we face convincing Governments to buy Open Source.

We need to be clear about the value of Open Source, and how to effectively measure that value. Once we know how to communicate the value we can then help government purchasers include selection criteria which foster the growth of these collaborative technologies.

And of course, I'm talk about what we as an industry can do to make our Open Source offerings more attractive to government.

Lets start with what governments look for:

At the root of government accountability is the need to address the Triple bottom line.

• value for the Community
• value for the Environment
• value for Money

This translates down to project selection criteria based around:

• Fit for purpose
• Value for Money
• Low risk

So now lets ask what is so great about Open Source.

• You pay for the software development once, and after that, its free, for everyone. Well, it is licence free.
• Following on from this: Others are actively encouraged to improve and extend your software, and depending on licence, these improvements are usually given away for free as well.
• Next, because the software is available for free, it is hard to apply vendor lock in tactics. Governments can change their support company without being forced to change their software. And this reduces long term project risk.

So far, I probably haven't told you much that you don't already know.

What we need to do now, is explain these strengths of Open Source in government purchasing terms, and introduce practical steps to promote Open Source Software.

Lets start by looking at one of the dark sides of proprietary selling. Namely Vendor dependence, or vendor lock in.

If an agency moulds its business processes around one product, and integrates key applications around the proprietary interfaces to this same product, then the agency becomes dependant upon this product.

This is called vendor lock in, and any government purchaser who has any grey will be able to cite examples of how they have been burnt by vendors who have forced them to pay increased licence fees, or have had forced upgrade cycles, are who have been left hanging with an unsupported product which the vendor has deemed to have reached end-of-life.

The key solution to avoiding vendor lock-in is to build applications upon Open Standards and this is an easy sell to government. Most agencies will support the use of Open Standards, as they see standards as key to reducing medium to long term risk of their projects.

Different sectors have reached different levels of maturity for standards. Our GeoSpatial sector have developed some very mature and widely adopted standards and this has been valuable for creating opportunities for Open Source.

Because once you break the proprietary silos, it then makes economic sense to replace components of the silo, bit by bit, with Open Source equivalents.

So lesson number 1:

Promote the value of Open Standards for reducing vendor lock-in, and hence for reducing long term project risk.

Also, ensure that your Open Source applications are standards compliant.

Now lets talk about some the standard gripes that people have with Open Source.

I'm sure that many of you have heard comments like:

"I like the idea of Open Source, but what other government agencies are actually using these same applications you're recommending to me?"

or

"We've thought about Open Source, but who do we call, who can we blame, when things go wrong?"

You see, only alpha-geeks purchase software, everyone else purchases products.

And in particular, governments purchase products. Because in order for software to be valuable, it need to address all the implementation and risk requirements that purchasers are looking for:

These include:

• Support
• Case Studies
• Training
• Warranty and Certification that the application actually works as specified
• And a hefty wad of user documentation

And that brings us to lesson number 2:

We in the Open Source industry need to sell products not software.

If you want government to deploy your favourite Open Source application, make sure there is an established company providing commercial support and training for the software. Presenting at this conference are many of the vendors who provide Open Source products, and also something that we at LISAsoft are launching for the GeoSpatial sector.

Now so far, I've been talking about Open Source applications as if you can take them out of the box and they will work straight away. Sort of like Microsoft Word, or the Open Office suite. And while some applications do fit into that category, most large government purchases require require non trivial customisation in order get new applications to integrate with existing systems. And that is what us Systems Integrators get involved in.

In this systems integration market, emerging Open Source applications are typically pitted against established proprietary applications. Usually both Open Source and Proprietary proposals need to develop new functionality to meet project requirements.

And this is where we it is very important for governments to get project selection criteria right, if they wish to give Open Source a fair chance during selection.

As mentioned earlier, Open Source is free once developed, so Open Source developers need to cover development costs up front. Proprietary vendors can charge less up front, then charge an expensive maintenance fee afterwards.

So lesson 3 is:

Ensure that purchasers evaluate the cost of the project over 5 or more years.

Next, we have already discussed the risk associated with a project being dependant upon an application. Purchasers should consider the full lifecycle of the project, including end-of-life. What will happen if the vendor stops supporting this application, or decides to apply unacceptable licence costs?

Of course, Open Source has an excellent story for these questions. Firstly, licence costs are free, so a stable old application can keep on working in the background without any licence fees required.

Second, governments can change their support company without changing their software. And this keeps the support companies honest.

Third, if my support company goes out of business, there is no licence restrictions to stop me going and hiring another company.

Fourth, your Open Source application is probably standards compliant, so you should be able to replace it with another standards compliant product.

So this brings us to Lesson 4:

Encourage purchasers to consider exit costs when they purchase software.

The next huge benefit of free software, is that once written, it can be used by, and benefit, many more communities than just the sponsoring agency. This is particularly pertinent to government which has thousands of government departments.

An Open Source application developed by one government department, will likely be of benefit to many other government departments. And the application will also likely be valuable to community groups that the government represents.

So Lesson 5 is that governments should assess the value of their purchases against the needs of the whole community, not just against the needs of the particular agency. If this one criteria were widely adopted by government, I predict that the majority of applications purchased by government would be Open Source.

And this is probably where we in the industry can help the most. You see, the Open Source industry is excellent at collaboration. Collaboration, and sharing your workload with external developers is exactly what makes Open Source so successful.

So Lesson 6 is to help governments find like minded agencies who would all benefit from the Open Source solution. At LISAsoft, we have been quite successful with this approach, partly because government agencies are already quite familiar with collaborating with each other to share development of proprietary solutions.

But if we limit our collaboration to just working with organisations that we can engage before we start a project, then we miss the core success factor of Open Source. Namely, if you have useful software, and you give it away as Open Source, then others will use and improve the software, and you, original sponsor, will benefit from these enhancements.

This core principle has been well understood for 20 years or so, and is basis for almost all successful Open Source projects, so why is it that Governments don't use it?

Basically, it comes down to the fact governments do not have the tools to assess the potential value of collaborative opportunities.

Governments need to make use of "Opportunity Management" to assess the value of collaboration.

"Opportunity Management" is the same as "Risk Management" but with the numbers reversed. Instead of identifying what could possibly go wrong, and then applying mitigation strategies to reduce the chance of the things going wrong, with "Opportunity Management", you identify what could possibly go right, and then deploy enablement strategies to give the Opportunity every chance of success.

For instance, I've about to build a super-duper widget which will be useful for governments and communities around world. I expect that if I spend an extra $20,000 Open Sourcing this application, then there is a 90% chance that some of these potential users will join my development team, and extend the application, adding another $300,000 worth of valuable.

So this brings us through to Lesson number 7:

When proposing a Collaborative Opportunity like Open Source, be sure to spell out the value in financial terms using "Opportunity Management".

Of course, Open Source is just one of the uses of collaboration in successful web based businesses.

Tim O'Reilly defined the key design patterns for a successful web business and called it web 2.0. Tim's Web 2.0 defines such things things as crowd sourcing information from your users in order to significantly reduce the cost of collecting and maintaining data.

Now the Australian government has actually been absorbing the lessons of Web 2.0 into government thinking, which they have coined Gov 2.0, and I understand that we will be hearing more about this from Pia this afternoon.

This Gov 2.0 has a focus on taking the collaborative and participatory practices into government in order to make governments more effective at engaging the community.

And this is good news for us in Open Source, because it is legitimising the value of collaborative technologies like Open Source, which makes it easier for us to sell Open Source right across Government.

As discussed earlier, Open Source changes the monetisation points in the sales cycle. Instead of paying a large company for software licences, which is then used to support an overseas software development team, you instead pay local developers and systems integrators to provide support and customisation.

And this takes us to lesson 8. Governments usually wish to promote local industry, and by promoting Open Source, they will also be advantaging the local software industry.

Even Leybourn explained another variant on this message in an earlier presentation, noting that in the business intelligence domain, it is more important to invest in people than in technology, which is one of the reasons why he prefers to use Open Source Software, and use the saved licence fees to invest in a better quality team.

So in Summary,

1. Promote Open Standards in order to reduce long term risk and break vendor lock-in
2. Sell Products, not Software
3. Evaluate value over the full life cycle of the project
4. Consider exit costs of solution
5. Consider value to whole of government and greater community
6. Look for Partners
7. Use "Opportunity Management" to describe the collaborative value of Open Source.
8. Open Source promotes local industry
9. Prioritise investment in people over technology