Tuesday Feb 24, 2009

UK Government Endorses Open Source and ODF

Tower Bridge

Late today (UK time), the British Government issued a bold new strategy for use of open source software - and open standards - in Great Britain. In Open Source, Open Standards and Re-Use, the government's Minister for Digital Engagement (yes, really, and he's on Twitter too) significantly revised the brave but toothless policy of 2004 "that it should seek to use Open Source where it gave the best value for money to the taxpayer in delivering public services". This is fantastic news - the digital tipping point is at hand. (The publication is also progressive in having nominated use of the tag "#ukgovOSS" in comment and coverage so it can be found and aggregated).

Like other fine policies before it, the core of the document asserts that the government

  • will actively and fairly consider open source solutions alongside proprietary ones;
  • will consider exit and transition costs as well as the total lifetime cost of ownership;
  • will pick open source where it doesn't cost more;
  • will insist proprietary vendors explain exit, rebid and rebuild costs;
  • will expect proprietary licenses to be transferable throughout government;
  • will expect public sector solutions to be re-usable
In support of this there are some key action items that include:
  • develop clear and open guidance for ensuring that open source and proprietary products are considered equally (action 1);
  • keep and share records of approval and use of open source (action 3)
  • support the use of Open Document Format (action 8);
  • work to ensure that government information is available in open formats, and it will make this a required standard for government websites (action 8);
  • general purpose software developed by or for government will be released on an open source basis (action 9).

This is all to be warmly welcomed and encouraged, and I congratulate the government on this progressive step. The endorsement of ODF is especially welcome, and would have seemed no more than an impossible dream to those of us associated with OpenOffice.org and involved in it at the start of the decade.

I will be very pleased to support and assist in any way that appropriate. In particular, I encourage the CIO Council to consider switching from an assumption of a procurement-driven approach to software acquisition to an adoption-led approach. Doing so does not favour open source; rather, it levels the playing field so that open source solutions can been seen alongside existing approaches. Sadly, if we stick with procurement-driven approaches and try to force-fit open source into them, we will be gamed.

Sunday Nov 02, 2008

Public Procurement and FOSS

Alcatraz

I gave an interview to a journalist last week in response to the research that the European Commission's Open Source Observatory publicised in Malaga last week and the corresponding draft procurement guidelines (thanks to Roberto for the pointers to the Malaga news). I was at the conference but a scheduling conflict prevented me attending IDABC's session, which I regret.

Good News

I very much welcome the guidelines; as I have been saying for well over a year now, the first step to encouraging the use of Free/open source software in the public sphere is to facilitate the adoption-led model in addition to the procurement-driven model, at the very least to the extent of encouraging two-phase procurement. As Rishab pointed out (although not with the same words), there are also the issues of substitutability and the freedom to leave, which I believe it's fundamental for a public administration to consider.

Substitutability guarantees citizens access to government without being forced to trade with a single vendor in order to do so, and the freedom to leave ensures public administrations always have the negotiating power to get the best deal for taxpayers. The guidelines begin to address those issues as well - great news.

Concerns

The journalist went on to ask me about all the documented procurement violations. It seems that:

Of a sample of 3615 software tenders that were published between January and August this year, 36 percent request Microsoft software, 20 percent ask for Oracle, 12 percent mention IBM applications, 11 percent request SAP and 10 percent are asking for applications made by Adobe.

That's bad enough, and likely illegal in most cases, but then it also turns out:

According to Gosh, software tenders often have either implicit or explicit bias for software brands or even specific applications. Of a thousand government IT organisations, 33 percent said compatibility with previously acquired software is the most important criterion when selecting new applications. Ghosh: "This implicit vendor-lock in means that a tender, meant to last for only five years, leads to a contractual relation lasting ten, fifteen years or more."

Most concerning of all, however, was that despite this all being completely transparent and public, the Commission is doing nothing about it. They regard the problem as being one that the competitors of the favoured companies should address through the courts. That would be fine if the market was largely functional and there were only rare cases of abuse.

But it's not. The improper procurement activity is endemic, and until that's addressed any competitor attempting to act through the courts is likely to find themselves discriminated against even further. It's never good to sue your customers (as the music industry is finding), and in a market where the customers can specify you out of the running with impunity, it's suicidal. Moreover, it can take years for the courts to make a ruling, which means even more lost opportunity for competing companies - assuming they can survive the wait. Until the European Commission takes adequate corrective actions to address this disease, there is no step in the current software market condition that any competitor is likely to take to address it.

Recourse?

Given the scale of the disadvantage already present, why would any player want to make their position worse? In the report of the interview the Commission representative says: "There are sufficient ways for companies and other organisations to protect their rights." He may be right, but they aren't being used by the FOSS community and the reason is that the abuse is too extensive for anyone to want to make the first move.

I'm delighted by the fact the new procurement guidelines exist, but personally I want to see direct action to establish them - it can't be left up to those already disadvantaged. I wonder if anyone has the stomach for it?

Sunday Mar 23, 2008

Why Adoption-Led Is Not Trialware

In response to my posting Adoption-led is Not Shareware, IBM's Savio Rodrigues continues the exploration of the adoption-led concept in another blog entry. As an explanation of his view that "adoption-led" is a synonym for "shareware/trialware" he has modified my original explanation to read:

In this approach, developers select from available Shareware or Trialware and try the software that fits best in their proposed application. They develop prototypes, switch packages as they find benefits and problems and finally create a deployable solution to their business problem. At that final point, assuming the application is sufficiently critical to the business to make it worthwhile to do so, they seek out the creator of the Shareware or Trialware to provide support, services (like defect resolution) and more. Adoption-led users are not all customers; they only become so when they find a vendor with value to offer.

Savio is correct to note, as Zack does, that Free software is easier to evaluate. The trap Savio is falling into here is to go no further and to be focus only on the procurement of the software. That's a natural reaction given the dominance of procurement-driven thinking, but it hides the natural progression of software in an adoption-led context. What matters is not the freedom to procure the software, but the freedom to adopt it. The two are only the same in a procurement-driven world.

Freedom to Use

No Fun

With trialware/shareware, one is only free to use the software for evaluation purposes. Once one switches to production, one is compelled to pay for a license to the software in order to take it into production. This causes significant problems in an adoption-led context:

  • It frequently means that the features needed for production are not present in the software in use.
  • It erects a barrier between evaluation and deployment that most likely involves a switch of versions, resulting in a need for re-evaluation. For example, if the evaluation was on Fedora, to go to supported production the system will need to move to RHEL, since Red Hat do not support Fedora (as far as I know).
  • It erects a payment barrier in the adoption process, one which is located at an arbitrary point known only to the vendor's legal team. Does one have to pay between evaluation and development? Between development and pilot? Between pilot and initial roll-out? Between initial roll-out and full production? Who knows?

True Free software (software with the freedoms left in) doesn't have these problems. There are no artificial barriers or toll-booths on the path to deployment, and adoption is a process that can be conducted under the control of the adoption team. As they progress they can decide at each stage whether to go buy a subscription from a vendor to meet their sustaining needs, or whether to engage experts from the open source community around the code to do it, or whether to just absorb the risk themselves.

This is the key to the adoption-led approach. It's about adoption of software, not about the procurement of software. It puts control in the hands of the adoption team. It's about freedom - freedom from vendor control, freedom to use the software how you want.

[Previous: Adoption-led as a Force of Nature | Next: An Adoption-Led Business Model]

Thursday Mar 13, 2008

Adoption-Led as a Force of Nature

Crater Lake Sunrise

In discussing how the software market is increasingly an adoption-led one, a frequent point of departure is to look at ways in which existing software companies are pursuing open source models.

Centralised to Distributed

But the idea that the adoption-led model is a go-to-market strategy created by software vendors is wrong. Although as Zack observes it has become a successful driver for some companies, it is fundamentally a consequence of a set of social changes which in turn are the consequence of the pervasive nature of the Internet. No amount of debate for and against an adoption-led business model will ever change the fact that the market is moving that way.

The first mechanised communications - dating back to before the Industrial Revolution - helped to create a hub-and-spoke social topology. The ability to communicate to a large number of people was necessarily centralised and recognition of authorship became more important. Interestingly, this is when copyright law first emerged. And as more communications became industrialised, so did society become more centralised. Author at the hub, readers at the spokes, suppliers at the hub, customers at the spokes, government at the hub, citizens at the spokes. The Web is changing that. The topology is changing to a mesh that even crosses cultures and borders. Peer-to-peer is the new order.

While the internet has existed for a relatively long time in technology terms, the Web as an application has driven it to ubiquity in a very short time. And this is what gave the equally long-standing Free software movement the vehicle it needed to influence the mainstream. The two together have placed a growing wealth of software within reach of every sufficiently skilled developer, giving them the freedom to use it however they wish. As Stormy points out, they can now bypass the whole existing system.

Demands a Response

It's this sudden wealth of choice which created the adoption-led movement that I described before. It didn't - and doesn't - need vendors to happen. Rather, it demands a response from vendors. Some try to ignore or to discredit it. Some pay lip-service to it, using its fruits but shunning true participation. And some embrace it, employing people to work within open source communities. Each of these approaches has business models associated. None of these approaches have themselves caused the adoption-led market to spring into existence.

Now, although this movement did not need vendors to make it happen, vendors have the opportunity to help it into the mainstream for business usage. As I suggested in my response to Savio, there's a lot of value that a vendor can add:

The model assumes that enterprise users will want the value-added content of a "subscription" or "enterprise version". Value-add can include patch management, performance tuning, additional utilities and more. Corporate governance regulations may make enterprises using software for a mission-critical purpose require a service contract, or seek a warranty for their software infrastructure. Those who are embedding software in their own product may require indemnification. Finally, many businesses are reluctant (for whatever reason) to use open source licenses and so want commercial licenses for their production systems.

To deliver on that value, it's my belief that the biggest opportunities lie beyond the mere aggregation of the work of others (although that does seem to be a viable option for some). I believe that through influencing the direction of a project, through employing committers to an open source code base, by creating new code, by being a responsible community steward and by bringing leadership to the challenges open source faces, a software vendor can take full advantage of the opportunities the adoption-led market presents. And I believe that success will be proportional to the contribution made. No free lunches, at least for those wanting job security.

Led, not Driven

This is the response of the software industry to the mesh topology. It's one where copyright, through open source licenses, is used to foster creativity, rather than to restrict access (and the inverse for patents - a reversal worth discussing elsewhere). We are moving from the "procurement-driven market" to the "adoption-led market". One is driven by vendors. The other is led by deployers and developers. That's the key, and I think other industries should examine with interest the lead that the software market is providing, since I expect the phenomenon to spread beyond software.

[Previous: Adoption-led is not Shareware | Next: Why Adoption-led Is Not Trialware]

Tuesday Mar 11, 2008

Adoption-Led is not Shareware

Change and the Cathedral

In response to my article last week on the emerging adoption-led market, IBM's Savio Rodrigues suggests this is just a description of Shareware and asks why anyone would ever pay for what they got free.

I can't say I agree. Of course, there are similarities between the two - in fact, I was closely associated with a successful shareware business at the start of the 90s, so I have a fair insight into how that works. We actually had close to 10% of estimated users registering our software. But what I am describing is not the same model.

First, what I am describing is a change in the software lifecycle which is facilitated by open source, rather than a business model which is initiated by vendors. Software deployers will switch from procurement-driven to adoption-led patterns without any intervention from vendors; it's a natural consequence of software freedom. The question really is not whether or not this market will come, but how vendors will remain relevant in it.

Second, this is not a support-only model. The model assumes that enterprise users will want the value-added content of a "subscription" (the model most closely associated with Sun to date) or "enterprise version" (such as the RHAT model). Value-add can include patch management, performance tuning, additional utilities and more. Corporate governance regulations may make enterprises using software for a mission-critical purpose require a service contract, or seek a warranty for their software infrastructure. Those who are embedding software in their own product may require indemnity. Finally, many businesses are reluctant (for whatever reason) to use open source licenses and so want commercial licenses for their production systems.

So I think people are more than willing to pay if what they are paying for reduces costs or adds value. It's the software that's free of charge, not the people who work on it. They benefit from the freedom Free software brings, and their employers or customers benefit from the choices that freedom brings.

[Previous: The Adoption-led Market | Next: A Force Of Nature]

Sunday Mar 02, 2008

The Adoption-Led Market

Fruit Bats, Asutralia

I've previously spoken of payment at the time of deployment rather than at the time of selection - Software Market 3.0 - as the defining characteristic of open source business models. As I've spoken about this in all sorts of contexts, it's become apparent that this is just an aspect of a deeper trend, which in some ways relates to Greg's red-shift/blue-shift idea.

Traditionally, the process of acquiring software has involved a request for proposal from vendors against a customer specification. Vendors then make proposals, submit prototypes, contend for business. In smaller bids, an evaluation team considers trial versions, makes evaluations, makes proposals to management. Eventually software is selected and paid for. At that point, adoption can begin. Every user of software in this model is also a customer. Software selection is something of a matter of faith in the procurement-driven market.

Defining Adoption-Led

The switch to a mesh topology for society1 has led to easy access for everyone to Free software created by open source communities. The result is an emerging approach which is rapidly spreading for smaller software projects and in my view is the future of all software acquisition. The emerging approach is an adoption-led market.

In this approach, developers select from available Free software and try the software that fits best in their proposed application. They develop prototypes, switch packages as they find benefits and problems and finally create a deployable solution to their business problem. At that final point, assuming the application is sufficiently critical to the business to make it worthwhile to do so, they seek out vendors to provide support, services (like defect resolution) and more. Adoption-led users are not all customers; they only become so when they find a vendor with value to offer.

Consequences

Written down like that, it seems pretty obvious, but having a name for it – an adoption-led market – has really helped pull together explanations and guide strategy. For example:

  • In a procurement-driven market you need to go out and sell and have staff to handle the sales process, but in an adoption-led market you need to participate in communities so you can help users become customers.

  • In a procurement-led market you need shiny features and great demos, whereas in an adoption-led market you need software that is alive, evolving and responsive to feedback.

  • In an adoption-led market you need support for older hardware and platforms because adopters will use what works on what they already have.

  • Adoption-led users self-support in the community until they deploy (and maybe afterwards if the project is still “beta”) so withholding all support as a paid service can be counter-productive.

Naturally now I have a new hammer everything looks like a nail, so expect to hear more of this if you talk with me!

[Next: Adoption-led is not shareware]


1. Described in more detail in Adoption-led as a force of nature

About

Thoughts and pointers on digital freedoms and technology markets. With a few photos too.

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today