Open Soure Maturity Model v2 · 2018-03-03 · Capgemini. 2. The document is reproduced in full -or- a reference to the original ... 10 .WHAT DOES MATURITY ... market dominance etc

Improving on the success of the original OSMM, Improving on the success of the original OSMM,

Chris Widdows and Frans-Willem Duijnhower Chris Widdows and Frans-Willem Duijnhower

have reunited to take it one step further, we have reunited to take it one step further, we

proudly present the next release of the OSMM v2: proudly present the next release of the OSMM v2:

OSMM v2.2OSMM v2.2

An improved way to objectively apply Open Source in your

Organisation

Open Source Maturity Model v2.2

OSMM v2.2 License - overview

The original OSMM license stated “This

document is copyright © 2003 Frans-Willem

Duijnhouwer and Chris Widdows. Permission is

granted to reproduce this document in either

electronic or printed form if the following

conditions are met:

1. Credit is given to the authors and

Capgemini.

2. The document is reproduced in full

-or- a reference to the original

document is provided.

3. Summaries of the document are

permitted providing they include a

link to the original document and

state clearly that the summary may not

be accurate and does involve the

copyright holders in any way.

4. Any additions are clearly marked as

not belonging to the original content.

5. It is forbidden to translate this work

in any other language without prior

consent of the copyright holders. For

any translation that is produced with

prior consent; the translator is given

full credit for the work.

All above conditions (if applicable) must

be met. For any situation not expressly

described here the normal rules regarding

copyright apply.

Any contributions to the document are welcomed; substantial contributions will of

course be credited.”

You can find the original OSMM and

supporting documents at:

http://open.widdows.eu/GB_Open_Source_Matur

ity_Model_1.5.5.pdf

Version 2 of the OSMM is a partial rewrite

of the first version by the original authors. The

license for version 2 is much easier to understand:

As of version two, the OSMM is

licensed under the creative common licence cc

by-nd. You can find the license deed here:

http://creativecommons.org/licenses/by-nd/ 4 .0/

For version and 2.2 onwards, the

attribution has been changed; Cognizant

Technology Solutions Benelux B.V.

(http://www.cognizant.nl/) has provided the

opportunity for the opportunity to keep

maintaining the OSMM. The OSSM can be

found at http://open.widdows.eu/

The full text of the license is included at

the end of the text. The original authors /

licensors are Frans-Willem Duijnhouwer and

Chris Widdows.

In the attribution you must include

that Cognizant Technology Solutions

Benelux B.V. sponsored the authors in their

effort to write the OSMM v2.2

Finally, no closed source was used

in the creation of the OSMM v2.2!

http://open.widdows.eu/GB_Open_Source_Maturity_Model_1.5.5.pdf

http://open.widdows.eu/GB_Open_Source_Maturity_Model_1.5.5.pdf

http://open.widdows.eu/

http://www.cognizant.nl/

http://creativecommons.org/licenses/by-nd/3.0/



Contents

.INTRODUCTION.........................................................................................................................................5

.WHAT IS OPEN SOURCE?...................................................................................................................................5

.WHAT IS THE RELATION BETWEEN MATURITY AND OPEN SOURCE?.............................................................................7

.THE HISTORY OF THE OSMM............................................................................................................................8

.WHY VERSION 2?.............................................................................................................................................8

.WHAT ABOUT MATCHING FUNCTIONALITY?.............................................................................................................9

.MEASURING MATURITY – AN OVERVIEW...................................................................................................10

.WHAT DOES MATURITY TELL US?........................................................................................................................11

.WHY LOOK AT WHAT HAPPENS FROM THE OUTSIDE?...............................................................................................12

.PROVEN TRACK RECORD...................................................................................................................................12

.PURPOSE OF THE OSMM.......................................................................................................................13

.A WALKTHROUGH.................................................................................................................................14

.THE VIEWPOINT..............................................................................................................................................14

.SCORING THE SOFTWARE...................................................................................................................................15

1.Differences between Open Source and proprietary products...........................................................................16

2.The areas of interest and indicators...................................................................................................................16

.THE DETAILS........................................................................................................................................18

.INTEREST AREAS..............................................................................................................................................18

.THE INDICATORS..............................................................................................................................................19

1.Interest area 'Product'........................................................................................................................................19

1.1.Age..............................................................................................................................................................19

1.2.Licensing.....................................................................................................................................................19

OSMM v2.2 -3-

Chris Widdows & Frans-Willem Duijnhower

1.3.Selling points...............................................................................................................................................19

1.4.Developer community.................................................................................................................................20

1.5.Human hierarchies......................................................................................................................................20

2.Interest area 'Environment'................................................................................................................................20

2.1.Collaboration with other products..............................................................................................................20

2.2.Modularity...................................................................................................................................................21

2.3.Standards.....................................................................................................................................................21

3.Interest area 'Acceptance'..................................................................................................................................21

3.1.User community..........................................................................................................................................21

3.2.Market penetration......................................................................................................................................22

4.Interest area 'Use'...............................................................................................................................................22

4.1.Integrator viewpoint....................................................................................................................................22

4.2.Consumer viewpoint...................................................................................................................................23

.THE SCORING.................................................................................................................................................25

1.Importance of measurable scoring....................................................................................................................25

2.The Score Card Approach.................................................................................................................................28

3.The criteria.........................................................................................................................................................28

4.Consideration to criteria expansion...................................................................................................................30

5.The importance of keeping up to date...............................................................................................................31

.A DETAILED EXAMPLE.............................................................................................................................32

.AN OVERVIEW................................................................................................................................................32

.IN DETAIL......................................................................................................................................................33

.EVALUATION, THE SECRET OF SUCCESS.......................................................................................................36

.ACKNOWLEDGEMENTS.............................................................................................................................36

.OSMM – LICENSE...............................................................................................................................38

OSMM v2.2 -4-


. Introduction

Welcome to the second edition of the Open Source Maturity Model, or OSMM for short. Since it's

introduction in 2003, the OSMM has proven to be a reliable model for determining the suitability of Open

Source products in a professional environment. Since then both authors have found new employment and

perception of open standards, Open Source has altered a little. This version is a continuation of the OSMM

v2, for which the authors thank Ordina's sponsoring. Since then the authors have moved one and this

release marks the recognition of the new sponsor, Cognizant Technology Solutions Benelux B.V. Because

of the applicability of the OSMM to IT landscape transformations, the authors were given another

opportunity to release a new version. This should be considered mostly a maintenance release. There is

some editorial work and the relationship between maturity and risk mitigation has been made more clear.

No changes to the license and / or copyright, the OSMM v2.2 is latest.

A word on attribution. As no one is charged for the use of OSMM, nor is anyone required to hand

over cash, there are no tricks to tease you and find ways to get paid later, it is very important anyone using

the OSMM does in fact recognise:

1. That this is predominantly the work of the two authors and copyright owners. In the past both former sponsors made the error of passing it off as theirs. Whilst the opportunity is greatly appreciated, this is in fact incorrect. It's ours and will remain so.

2. Sponsors help out a lot, and we're more than willing to acknowledge what they did for the OSMM. So when you use the OSMM, please make sure you understand that our sponsors have all made this happen and in a way, ensure it continues to happen.

3. You will violate the license by trying to pass this off as yours, regardless if you are or have been a sponsor. This means you risk being dragged to court, all it takes is for you to give credit where credit is due. Is that so much to ask? Significant contributions are attributed in the document, don't make claims that are not in the document. If you believe the document does not recognise your effort properly, get in touch and we will make it right..

. What is Open Source?

In order to understand why you would need to determine maturity it is key to define what is Open

Source. The definition of the Free Software Foundation1 stipulates that you, the user should enjoy 4 specific

forms of freedom:

1 http://www.gnu.org/philosophy/free-sw.html

OSMM v2.2 -5-


1. The freedom to run the program, regardless of purpose

2. The freedom to understand how it works and to alter how it works

3. The freedom to give the program to someone else

4. The freedom to give your changes to someone else.

In this context, freedom is comparable to open, you are free to do if what you want to do is open.

Free is not the equivalent of being without cost. In the words of the Free Software Foundation is that it is

free as in 'free speech' not as in 'free beer'. The Open Source Initiative2 has a more elaborate definition and

formulates 10 characteristics:

1. Free redistribution

2. Access to Source code

3. Allow for modifications and derived works

4. Integritiy of Author's source code

5. No discrimination against persons or groups

6. No discrimination against fields of endeavour

7. License is distributed

8. License not tied to a product

9. License does not restrict other software.

10. License is technology neutral.

In essence both agree on that the right to use and modify as you see fit and the right to learn 'how it

was done'. In short Open Software does not seek to limit, but actively seeks to share. It is clear that given

these dynamics, it would be hard to see a viable business model that wants payment for giving you a copy

2 http://www.opensource.org/osd.html

OSMM v2.2 -6-


of their software. There is no limit / restriction on having the right to share, so it would be hard to get paid

for all the copies in circulation. This gives rise to alternative business models most commonly rooted in a

form of providing a service. For instance, you could ask payment for making certain changes, but under the

same logic, not for sharing the change. You could ask to be paid for ensuring the use of the software in a

certain setting is possible.

The OSI maintains a list3 of licenses, well known examples are the GNU Public license, Apache

license and BSD licenses. Licenses that have not been validated by either the FSF or OSI can still be open,

by looking their compliance to the given definitions. Each license grants the same basic freedom, but they

differ in the consequences of that freedom. Some require you use a similar license for other parts of your

solution, in varying degrees.

. What is the relation between maturity and Open Source?

The freedom ensured by adhering to the definitions of Open Source makes this an appealing model

for a more organic development model. You have an idea, start work on it, people join in and the idea is

realised. These people form groups around the idea, these groups are commonly known as communities.

There is no organisation, other than required to regulate and communicate efforts on getting somewhere.

Good ideas attract a lot of attention, some ideas don't. Market need is a much stronger factor. With the

absence of monetary rewards, the knowledge, the result itself has to provide worth.

It is in this organic nature that maturity becomes interesting. A company can be judged on it profits,

new products, turnover, market dominance etc... It can go belly up for reasons of mismanagement, sudden

decrease in sales etc... There is a lot of literature on what figures mean what to a business. The same applies

for determining if that business will be able to sustain.

With a community that earns no money and makes no sales, you cannot apply the same logic. But

what does work is observing how the community behaves. Think of a start up, one person puts his/her heart

into realising a dream, as the owner expands, the need for employment contracts, benefits, meetings,

vacations etc.. increases. The larger the group, the greater the need for structure. A more accomplished

community will be forced to either introduce increasing forms of procedures, ways to deal with increasing

demands, influx of ideas etc... At a certain point it may stabilise, or simply cease to be. But a more mature

community is an indicator for a more successful initiative.

3 http://www.opensource.org/licenses

OSMM v2.2 -7-


What is different is that how communities do this does not need to meet 'common industry practice' .

You could look at communities and apply a checklist and score that. Do they use DevOps? Do they have

work procedures, does their software validate against something? The OSMM deliberately does not go

there. As long as the people in the community are happy with how things have been set up, we're good. If

you don't document your code, common wisdom has it that on-boarding new blood is going to be hard. But

if we see a thriving group of fresh developers, it doesn't matter how, but it is clear the community is

attracting more development resources and that's good. This approach is favoured by the OSMM, don't

check how it is done, but for content within the community. It makes the OSMM more flexible, it reduces

the need to keep plugging in the latest buzzwords.

. The history of the OSMM

In 2002 during the discussions on how Open Source could be brought out the then commonplace

strongly emotional discussion. Instead of declaring yourself to be for or against, it was felt that a way to

measure the worth of the community in a way that would support an objective evaluation of the group of

people writing the software to allow it to be seen as safe as any established software companies. And based

on facts, rather than any perceived value.

Based on this idea, the authors started to write the Open Source Maturity Model, which initial

version took almost 2 years to materialise. Several nights/evenings were spent writing, discussing what

should go in, what not.

After completing the first version, subsequent modifications saw the model tuned, it was tested and

adjusted to ensure the outcome was meaningful. The OSMM was built from two components, the maturity

model and the suitability measurement. Basically the idea was that you needed a minimal level of maturity

(i.e. a certain absence of the risk it would cease to exist) and a certain suitability of application. As there

were no documented ways of finding suitable products, the authors came up with a personal list of things to

look for.

. Why version 2?

If we look at the application of Open Source nowadays, we see that things are changing. There is less

emotion than almost 10 years ago, but there is still a significant portion of gut feeling ruling the decisions to

do or to not do. What has changed is the ratio between do and not do. Political pressures have moved the

OSMM v2.2 -8-


discussion out of the realm of technology, geekyness etc.. and into houses of representation. The arguments

used have been expanded, but not all arguments have contributed to levelling the playing field between

Open Source and closed source. In some fields, Open Source has been promoted to preferred background,

whereas others stay firmly with the closed source is more trusted mantra. Ideally the OSMM strives to

create a level playing field, Openness sometimes greatly adds to the value, sometimes it doesn't. A lot of the

decision to go with Open Source or not also depends on the field of application, and the strategic goals of

the entity that wants to use the software.

The second version of the OSMM has two major changes, to address the changed world:

1. The maturity measurement now allows for viewpoints. The original OSMM was devised from an

IT perspective, an IT firm wanting to offering a solution that contained one or more Open Source

components/packages would need to assess what was what. But for end users seeking the same,

the indicators were not as suitable. The OSMM v2 defines viewpoints and swap the the

indicators to address this issue.

2. Matching the suitability. The original OSMM included a situational part, in which part was

motivated by the absence of a open, documented way. Strictly speaking, this part doesn't concern

itself with the movement driving the development of the software, but addresses the manner in

which the software contributes to the objectives of use. In fact, this part of the OSMM doesn't

really belong to the first part, so it has been removed.

. What about matching functionality?

Clearly, any important decision to implement and start using software cannot be decided based on the

evaluation of the group that created the software. Every form of use has requirements, features that must be

present, features you would like to be present. How does the functionality / expandability fit with your own.

How costly would it be to train people, what current experience would no longer be needed. In all, there

should be selection process.

Initially the authors expected to find a ready made solution. After all, many firms offer services that

aim to help you decide, to choose. It's a bit like a software dating service. But as with closed source, there is

no transparency. No way to incorporate all the experiences from the people that have to live with the

choices made, or have paid good money to get it right. No transparency, so how can we be sure the

OSMM v2.2 -9-


followed procedure does not favour a particular background, such as being open or closed? After all, if

openness is important, the process should not be so biased as to still favour a closed source solution. If an

organisation mandates the use, the procedure should guide you to those products that embrace open

standards and not be all about proprietary standards and just pay lip service to the open ones.

Clearly there is a synergy between knowing something about the background, the maturity of the

product and its ability to add value to your situation. If you can look at the community that builds it, and

make it fit into a concise model, why can't you do the same for the contextual part? Initially this was

included in the OSMM, put they are very distinct. During the creation of OSMM v2, the authors decided it

would make more sense to plit of this part, and rebrand it as the OPSP. It's a framework to allow you to

select products on a 'fit for purpose' dimension. It can be used for both Open Source and commercial

offerings alike. The OPSP works well together with the OSMM, which is for Open Source exclusively.

Consequently for commercial offerings you need to supply your own 'maturity' model for the quality risk

mitigation. It is not within the scope of this model, or the OPSP framework, to target the commercial

offerings. The OPSP is slightly less mature, hence the license is more permissive, and it aims to provide a

open framework for determining a 'fit for purpose' assessment for a short list. Many firms claim to be offer

this service, but seem to prefer to not provide you with the details of how they assess. .

. Measuring Maturity – an Overview

Usually Open Source software isn't really a product, not initially. It's an effort, usually to solve some

actual problem, which gains a certain momentum and support. Instead of coming up with an idea that is

there to make money, the idea is to solve a problem. Some efforts are very specific, for instance OpenSSH,

which is an SSH package only, but some are very large, consider a Linux distribution or something like

LibreOffice or MySQL4

4 Currently in OpenOffice / LibreOffice debate, LibreOffice seems to be gaining the upper hand. OpenOffice has

become part of the Apache Software movement. Due to licensing choices, LibreOffice can add OpenOffice

improvements, but the inverse isn't true. In Open Source terms, LibreOffice is therefore more protective of the

freedoms. For instance GPL2 can take FreeBSD code on board, but not vice versa. In the MySql / MariaDB face off

things are decidedly less clear. MySQL is a polished offering with professional support, yet is not 100% opened up.

MariaDB has some exiting features, has tweakability, but will require a more committed user. It is possible to set

things up you can swap over from one to the other, but only if you plan it. This is evidence of how Open Source

evolves, the choices it offers.

OSMM v2.2 -10-


In some cases the effort becomes a product, the Linux kernel has given rise to several companies and

individuals putting together the base kernel and loads of additional packages to form what is commonly

know as Linux, but is in fact a software distribution including the kernel and loads of free supporting

software packages to form an usable operating system. RedHat, Novell are commercial companies

maintaining their own flavour of 'Linux'. But sometimes it is a more personal effort, such as Slackware, in

which Patrick Volkerding plays a pivotal role.

. What does maturity tell us?

In many ways the diversity shows the true power of Open Source, it provides for a open licensed

operating system, not burdened complicated schemes to restrict growth, and grown it has, nowadays it is

hard to find a consumer grade WiFi router or similar not running a form of Linux, or a media player for that

matter. Although Linux was into 64 bits from a very early stage as well, it still can be targeted to run on

lowly spec'ed hardware. On the other end, it can run well on seriously large computers as well. It fills voids

that would be hard to fill otherwise. Over time, many companies have abandoned their own efforts and

moved to a more service oriented approach and have offered supported version of free software. IBM,

Redhat are examples, but many others. In terms of maturity, Linux is probably the easiest to gauge. It has a

massively large community, it has seen commercial enterprises come into existence, offering support,

SLA's and all the stuff we see in enterprise environments.

Linux therefore could be rated as so mature, it is unlikely that it would disappear. Even if all the

current enthusiasts stopped tomorrow, the reliance on this software is such that most likely many firms

would consider investing in continuing the development. Using Linux therefore represents a very small

operational risk.

Another characteristic is scale. Once an Open Source community takes off, potentially it can attract

lots of people. In case of Linux, more than 1000. But the thing is, Linux can attract an almost unlimited

number due to how the community is running development. A commercial company, due to the way they

earn money, will always have a hiring cap, unless they accept a loss of value. BTW, several hundreds of

companies are involved in Linux as well. This ability to expand, shrink and become massive is a dynamic

commercial vendors can't offer. 5

5 http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/

OSMM v2.2 -11-


http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/

All this can be measured, just by looking at the degree of organisation, kernel versions are

maintained by their own maintainers, there are rings of trust around the people responsible for bringing out

changes, fixes etc.. There are many user-boards on the web devoted to supporting Linux, most of them

generating a lot of activity. If we look at the community, we can easily see that is behaving itself in a

manner that fits with the duration of the effort, the size of the effort and the need for the effort. A more

compact and easier term for all this is to say Linux, as an Open Source community is very mature.

. Why look at what happens from the outside?

One of the things the initial version of the OSMM lacked, and for that matter still lacks is the

examination of how things are accomplished. The OSMM does not seek to verify that development is

conducted using a formal Agile process, or that Prince II is used to manage the effort, or that documentation

is according to some standard. The OSMM very deliberately looks at the awareness of the group on how

things are done, but does not pass judgement on how it is done. You score points by being aware of how

you do it, but affords you the freedom to choose how best to do it.

Other models do take a close look at the internals of the community, and in certain circumstances, for

instance a company looking to align it's own developers to a certain community, this can be of use. The

OSMM does not seek to answer that question. It primarily looks at the ability to govern oneself, assuming

that each effort has its own right to choose whatever works best. Even so, many communities develop very

similar strategies for defect management, drawing information from their users. It is these behavioural

observation the OSMM uses, as they fit the objective of the OSMM.

. Proven track record

One of the strengths of the OSMM is that the original version was actually tested and calibrated.

Many meetings have been held, mostly on wherever to include one indicator or another. In nearly all the

cases, careful examination showed that new indicators introduced a slant (i.e. indications moving in sync,

thereby biasing the outcome), or did not actually prove to be good indicator of what was intended. By far

the calibration was an essential part of the process. Here our sponsors were helpful as they provided access

to the in-house experts that were able to quickly calibrate..

OSMM v2.2 -12-


Since then, the OSMM has been used in Europe by its first big user; Capgemini. Within parts of

OSOSS (a governmental body supported by the Dutch government, later replaced by NoiV) it was also

considered a very usable tool. It has successfully been used in large scale projects using Open Source. The

OSMM v2 has already established its value, being used in project of that sponsor of the OSMM v2, Ordina

N.V. By splitting off the framework to measure ' fit for purpose' and aligning the OSMM v2 so it can co-

exist with this framework, the authors are confident that the model becomes a more useful component of a

range of tools enabling the considered and successful use of / adoption of / transformation to Open Source

within a wide range of situations. With our current sponsor, Cognizant Technology Solutions, the authors

now have access to over 200,000 highly skilled associates that now everything there is to know about

current technology and software offerings. And for the first time, instant access to a global network that is

dealing with the professional use of Open Software on a daily basis.

. Purpose of the OSMM

One the main objectives of the OSMM is to be able to understand the level of maturity of the group

that is developing the software. The more mature, the more you can rely on the group and their ability to

actually help you. A more mature community results in a more developed, more useful, i.e. a more mature

software program. The level of maturity is therefore indicative of the backing the program will receive,

much the same as deciding between a start-up and well known brand in the closed source situation.

Understanding the maturity of the group provides a better understanding of where the software is

coming from, and where it is most likely to be heading. It demystifies the concept of community based

development, which, just as Open Source in general, is something a lot of people and businesses are not

used to dealing with.

The OSMM helps you to level the playing field in being able to select suitable sources for your next

software solution. It does not deal with closed source, but brings Open Source up to much the same level of

understanding. By having a strong focus on well defined criteria, using quantifiable indicators rather than

subjective indicators, it delivers more consistent results than a lot of other approaches. The better the

consistency, the more usable the output. At least, if we take into account what the aim of the OSMM is.

OSMM v2 is a more focussed effort than the first version, and allows for a more flexible application.

The OSMM v2 is supplied with a template allowing end-users to fill in the indicators. It is hard to be exact

about the effort involved, as some indicators require a little investigation, or in-depth knowledge of the

involved community. But asking people from within that community, or hiring an Open Source consultant

OSMM v2.2 -13-


to do the job is an option. The task of assessing any community should be doable by anyone that can

effectively search the internet in no more than 2 hours. Any expert should be able to complete an

assessment in less than 15 minutes. Of course, this assesses the source, the applicability to a particular

situation will normally require a lot more time.

Once you have measured a community, the outcome has to to mean something for it to be trusted.

The OSMM pedigree is one of the reasons the outcome can be trusted. It has been available for some time,

used by several organisations. The OSMM uses measurable factors, it does not rely on your views of the

community or ideas on Open Source. It doesn't aim to ensure all Open Source is good, just like in a closed

source environment, there are firms that are more suitable than others as software suppliers. The OSMM is

a tool you can use to find the more suitable communities, nothing more, nothing less.

Assessing the maturity is a way in which we mitigate the risk of going with the Open Source

equivalent of vapourware. With Open Source there's no requirement for an escrow agreement, the source at

least is free for you to copy and keep. A mature community knows what adds value, what doesn't, how you

create a community of users, how to build things. You simply run less continuity risks with a mature

community. So the OSMM serves a vital role in risk mitigation. One other product the authors wish to

mention is the OPSP, the former second portion of the OSMM, and the first open product selection process

tool that is transparent and guaranteed to not have any bias towards a particular form of software creation.

. A Walkthrough

. The Viewpoint

A new element introduced with OSMM v2 is the concept of a viewpoint. The first version was

basically the OSMM using a fixed viewpoint, which was the IT integrator's viewpoint. The software being

looked at was part of the solution and a certain IT proficiency was assumed. OSMM v2 adds a second

viewpoint, I want to use software X and that is the solution. My IT proficiency is not really a factor.

This doesn't mean only non IT proficient people or organisations can use the second viewpoint, or

that only IT companies would find the first viewpoint useful. The first viewpoint is basically 'I want to use

and build upon' whereas the second is more 'I want to use and be supported'.

The first decision is to decide which viewpoint is most appropriate, but there is nothing stopping

anyone from using both, you will simply see the maturity from two angles.

OSMM v2.2 -14-


. Scoring the software

A review of an Open Source product is different from a review of a proprietary product. Whereas a

proprietary product strives to protect the intellectual property, an Open Source product is focussed on

protecting the freedom of sharing that intellectual property. Rather restrict use, it restricts restriction of

freedom.

A brief overview of some of the differences clearly shows why the key comparison indicators are so

different.

OSMM v2.2 -15-


1.Differences between Open Source and proprietary products

Open Source products are freely available and naturally that is not the case for proprietary products.

Generally the users of a proprietary product do not receive the source code of the product, whereas users of

an Open Source product expect to receive the source code. Some of the other differences between these types

are presented in the table below.

Proprietary Open Source

Supplier a company a community

Product

developmentdriven by corporate economics driven by product functionality

DevelopersLimited numbers with product knowledge, all paid for by the supplier

Varies from a small to a very large group of developers. Often permanently employed, sponsored or volunteers.

StabilityNew trends are incorporated quickly if there is a commercial incentive. This does not always enhance stability.

New ICT developments are incorporated into the product if this benefits the users.

UsersCommonly not organised, every user maintains contact with the supplier independently.

Users participate in virtual communities and discuss among themselves and with the developers about the product and future developments.

There are many more differences between Open Source software and proprietary software. But the table

already shows that there is genuine need to evaluate Open Source products based on a different set of values

from the ones used for proprietary products.

2.The areas of interest and indicators

The OSMM v2.2 assessment consists of 13 questions, covering 4 areas of interest. One area of

interest represents the viewpoint, the others are the same regardless of the viewpoint. Each question is a

maturity indicator. The OSMM v2.2 has 16 maturity indicators in total, of which 13 are used per viewpoint.

OSMM v2.2 -16-


Each indicator consists of a question and three pre-defined criteria. These criteria are linked to a

corresponding indicator score, 1, 3 or 5. Based on the answer, one of the criteria will match and for those

situations where two criteria sort-of match, an intermediate score is used (2 for the 1 and 3 situation and 4

for the 3 and 5 situation).

By answering all questions you will calculate a total score and a score per interest area. The score is a

non weighted average of the answers in that area. As the rule of thumb, the OSMM v2 considers any score

below 3 to immature up to the point you should really know what you're doing to go ahead using it and any

score above three indicates that the maturity of the software is high enough to be used without undue risks

(i.e. there is some support, it is probably not going to be abandoned in the near future and there is a level of

support and organisation acknowledging a demand from its users and attracting enough interest to allow for

proper development.

When the score is 3 exactly, you need to look at any danger signs, meaning individual answers of 2

and below. Looking at the results per area will give you some idea of future options. It is quite common for

a project to start in a wave of enthusiasm, attracting increasing support, but only attracting commercial

interest in a later stage. With scores of 3 and up, if you see the area Use score lower to the others, it usually

indicates that the effort is still gaining momentum, scoring 3 is indicative of things stabilising. Should Use

score better than the others, you need to look at the details. Some products have an inherently finite feature

set, for instance OpenSSH6 is such a product, requiring upkeep in the form of maintenance, but not so much

massive new features would be expected every so many months. But a lot of people use it and it is unlikely

it would be abandoned any day soon. Contrast that to software like FireFox7 or OpenOffice8 where new

functionality is almost as important as fixing old problems.

As of version 2, the OSMM comes with a spreadsheet to allow you to easily enter and see the results.

It is nothing you couldn't have come up with, but it makes it just a little easier to come up with the answers,

after all the OSMM is there to provide answers, not test your computer skills.

6 http://www.openssh.com/7 http://www.mozilla.com/en-US/firefox/8 http://www.openoffice.org/ or http://www.documentfoundation.org/ depending on if you prefer the old or the new

incarnation of the same.

OSMM v2.2 -17-


http://www.documentfoundation.org/

http://www.openoffice.org/

. The Details

. Interest areas

Product indicators are grouped into 4 different interest areas:

Product

Environment

Acceptance

Use

Each of these groups consists of a number of indicators, which together form the maturity score. The

group Product focuses on the ‘internals’ of the product, things like the development and stability of the

developer group or the purpose of the product. The group Environment looks at the product's relationship to

its surroundings. It focuses on the 'externals' The group Acceptance looks at the social aspects of the

product. What do others (the users, the professionals) think and act with regard to the product. The Use

group is all about the options you have with regard to deployment. This group also contains the viewpoint,

you either select the use as an user, or use as an integrator. For an integrator the ability to connect to the

developers is more important, or the availability of market references. For an user there is stronger need for

help, either by communities or by third parties is more of an issue. In the case of third parties, local partners

are more valuable than those far away. If you are an integrator, working with global support options is much

less of an issue.

The manner in which an indicator is applied to an Open Source product is described for each product

indicator.

OSMM v2.2 -18-


. The indicators

1.Interest area 'Product'

1.1.Age

The longer a product remains under active development, the smaller the chance becomes that the

developers suddenly stop. For all Open Source initiatives the first year is the largest hurdle. Commonly the

initiative is halted due to lack of response (lots of work, no glory) or that the group is too small to sustain

the workload that the product generates. As long as there’s no financial compensation for all this effort the

group must attract new developers or seek a product sponsor. Either of these will allow the group to sustain

the development effort. Initiatives that have existed a long time, but have been dormant for some time will

benefit from this definition, however this presumed advantage is negated by lower scores (for instance for

market penetration and user community) for other indicators.

1.2.Licensing

Open Source products can choose from several different licenses. The choice made tells us something

about the way in which the intended users are approached. Some are very restrictive, so restrictive in fact

that they become the subject of discussion if the product can still be considered Open Source under such a

license. Some companies try to find ways in attracting large numbers of non-paid developers (something

Netscape tried for some time), allowing the company to lower the development costs. Others offer several

licenses; even catering for commercial variants (MySQL does this).

1.3.Selling points

Products with a clearly defined selling point more easily gain market share. Take Qmail (an MTA9)

for example. Despite sendmail being the accepted standard, it still managed to gain a sizeable market share

and create an active community. The reason: Qmail was developed because of difficulty experienced when

trying to configure sendmail to be a secure MTA. Qmail’s selling point; it addressed an important weakness

9 MTA is a Mail Transfer Agent

OSMM v2.2 -19-


of sendmail. But if we look at all the different Open Source GUI toolkits we see a different picture. Despite

a large number of high quality toolkits being available, new ones keep popping up again and again. The

newcomers have no clear selling points and usually don’t last very long.

1.4.Developer community

The saying ‘many hands make light work’ certainly holds true when dealing with an Open Source

product. Changes to people’s ambitions and personal life frequently result in that person moving on to do

other things. The greater the group of active developers the less chance that the product development stalls.

A large group also requires that the group must organise to continue to effectively work together. Group

organisation is one of the driving forces behind an effective community.

1.5.Human hierarchies

Projects with one all-controlling leader tend to last just a short time. Projects that delegate control to

other active members (usually dividing the project into separate areas of attention, allowing the original

‘captains’ to explore newer avenues) have matured more. It not only allows the project to grow whilst

maintaining the stable’ version, it gradually increases the supporting community

2.Interest area 'Environment'

2.1.Collaboration with other products

As the product gains acceptance within the target audience the call for the ability to work with other

products is heard more often. Usually the request to be able to ‘script’ certain aspects of the product’s

functionality is the first feature that points to interoperability. The next step is the incorporation of more

structural changes, like using PAM (Pluggable Authentication Module, a generic interface to allow

interaction between a product and a separate authentication system) for example. Collaboration with other

products is therefore the result of change requests that have been accepted by the development team. So it

isn’t just the product that is collaborating.

OSMM v2.2 -20-


2.2.Modularity

As an Open Source product gains more market share, others could become more interested in parts of

the product’s functionality. This allows the developers to develop a more flexible licensing scheme

(protecting the core, but allowing fewer restrictions on other parts), which could even allow commercial

developments to hook up to parts of the system. By splitting the product into several modules commercial

interest can be attracted without sacrificing the Open Source principle. This is what happened with Xfree

(XFree86), the X-server used by most Linux distributions. Previously video card manufacturers where

required to give out all the card’s inner details to get Xfree to work with their card. This was changed to

allow (closed source) binary drivers to hook up with the rest of Xfree. The users gained access too much

more recent and powerful hardware and video card manufacturers were now more involved in supporting

Xfree. The opposite also happens, proprietary products are offered in a trimmed down version to users as

Open Source, while the full product remains proprietary (closed software).

2.3.Standards

In the world of proprietary software setting your own standard is still seen as a way to protect the

investment in the product. For Open Source products adhering to widespread and accepted (open) standards

is extremely important. By only supporting standards that are common in just a couple of environments can

adversely influence the acceptance of a product. This depends a lot on the product itself, for instance a

product can connect to a database using a direct connection (limited to certain databases), ODBC (standard

in use in Unix/Linux and windows) or OLEDB (standard only used in windows).

3.Interest area 'Acceptance'

3.1.User community

Some products generate hardly any noise; some have several busy discussion groups. When an Open

Source product is well received it is common to witness an outburst of user requests, suggestions and

problem reports. The discussion group quickly fills up with large numbers of messages, so the developers

must expand and start to manage this huge flow of feedback. This could be described as an Open Source

project’s puberty. An active community is not to be underestimated. When Sybase stopped all development

on Watcom C++ (a developer’s tool) the community rallied and negotiated an open source option. Today it

lives on as Open Watcom C++.

OSMM v2.2 -21-


3.2.Market penetration

The installed base tells us something about the importance of the product within the intended

audience. A product with a large installed base provides additional stimulus to form communities. Apache is

a good example of this. Users will want to voice new requirements, discuss problems, and therefore require

a platform to do so. Some users may have clear ideas on how to advance the products; others will

appreciate the possibility to communicate directly with members of the development team. A larger

installed base indicates a more mature product.

4.Interest area 'Use'

This interest area sees most of the change for the new version of the OSMM, it now adds a viewpoint,

each viewpoint comes with a particular set of indicators. The original viewpoint of the original OSMM is

more or less the same as the 'integrator' viewpoint in OSMM v2.

4.1.Integrator viewpoint

4.1.1.Support

The amount of support you can get is partially dependent on the community, but in addition, dependent

on the amount of support you can find in the professional arena. Is there a commercial backing offering

services? Perhaps even one that is experienced in the setting you seek (similar size of clients, or legal setting,

cross-border or local only...). The better the match, the greater the support, lowering the risk of a deployment

gone wrong. It is important to realise that this may well be the own organisation that has this ability.

4.1.2.Proven

A big factor in any integrators life is finding a suitable product by also seeking references. Has the

product proven itself in different settings, are there success stories? Are those people approachable for a

quick verification? There is a big difference between seeing it work in a lab setting, or in real life doing what

it intends to do. Open Source products usually arise from a desire to solve something that is not easily solved

by existing products, or at an unacceptable cost (in this sense, cost may mean more than money). Seeing it

work and solving what it intended to solve is therefore a natural phase in the products existence. But to find

OSMM v2.2 -22-


people admitting to that is a next step. When Linux was usable, but not nearly as well known and popular, its

use preceded its admitted use. However, nowadays, it is almost too easy to find many situations where it is

used daily, and with great success.

4.1.3.Architecture

With most solutions envisioned by integrators, there's a vision of how things should work. Not only in the

way it communicates, but also in the way the vision of the integrator matches the vision of the community

creating the product. What is the context the community has set themselves for this product, is it able to grow

in the desired direction. With some products, it's irrelevant, with some it's important. But it is important to

see that it has at least been discussed. The vision translates to a, in varying degrees, visible architecture and

is an important indicator for integrators. If your vision includes web-based, SOA10's, ESB11's and the like,

having a desktop solution only does not help. The OSMM doesn't measure the suitability of the product in

this sense, but it does measure your ability to be able to match.

4.2.Consumer viewpoint

The second viewpoint the OSMM v2 sees is that of 'consumer'. The term consumer does not indicate

absence of IT skills, but the way it will be deployed. An integrator wishes to develop a complete solution in

which the product is integrated. He would expect to provide some support directly, using the available IT

skills, augmenting them with support from the different product communities / developers. The consumer

expects to be supported in a more direct fashion, by parties that supply all the required support in a

professional manner. These parties are more accessible, by being on-premise, aware of the business situation,

local regulations and laws. The difference is not set in stone. The OSMM v2 can also be run for both

scenarios, providing a score for usage that requires you to manage the IT support options and a score for

usages where the IT support is managed for you. A high integrator score but a low consumer score suggests

that the amount of support management is relatively low, an inverse score suggests it would be hard to add

value as an integrator using this product. Scores that are comparable indicate a similar lack or surplus of

options in that scenario. Although somewhat similar in name at times, the indicators are scored differently,

yielding the desired measurement.

10 Service Oriented Architecture. Think of lots of island cooperating to get things done, each island being distinctly

responsible for something11 Enterprise Service Bus. Think of a rail-road track in between all your components, with everyone having to fit to the

same kind of track.

OSMM v2.2 -23-


4.2.1.Support

When you use a product, you need help. Help is sometimes given by the developers, by a growing

community of users, by firms offering support. This kind of support needs to be more forgiving to

accommodate people with a non-IT background. For example, one of the great strengths of a Linux

distribution such as Ubuntu is the large, active and friendly message boards that offer answers to almost any

problem you might encounter. This support transcends the scope of the product itself, you'll find questions

on how to add software for which there is no support, and frequently find step by step solutions that require

no real knowledge of Ubuntu. A second important characteristic of consumer support is that it is close at

hand. A message board, being 24/7 is close at hand, but language barriers might prevent quick use. A

professional offering support services is of little use if it requires flying in from another continent.

4.2.2.Proven

For a consumer this is different than for an integrator. For instance an integrator might be well aware

of local rules and regulations and capable of determining the products match to a particular environment.

But a local council would want to be sure it can be made to comply with local rules / laws / regulations. It is

not enough to find a reference, you need a local reference. You need a reference in consumers context. If

I'm a small medical practice, the reference would be for a small to medium medical practice. The assurance

of an IT company that it can be done helps, but seeing someone having done it counts more.

4.2.3.Deployment

If a product becomes so popular that even independent parties start to offer training courses, it is

almost a certainty that it has become a mature product; the very least it has become a very popular product.

More commonly seen with Open Source is that active users start writing task specific papers (how-tos).

These how-tos allow new users to accomplish the desired functionality without having to master all of the

product capabilities. How-tos cover all aspects of product usage, not only how to set-up for a particular

application, but also how to maintain the product. Existence of documentation detailing day-to-day

maintenance is an indication of maturity.

OSMM v2.2 -24-


. The scoring

1.Importance of measurable scoring

One of the aims of the OSMM is to remove emotion, chance from how you perceive the people

behind the product. The indicators therefore should provide clear criteria for the scoring process. The

OSMM v2 scores every indicator on a scale of 1 to 5. It defines the criteria for the answers 1, 3 and 5,

leaving the scores 2 and 4 for situations where some criteria are met, but not all.

Over time it has become clear that it is not the number of criteria that has the biggest impact, it is the

criteria and the clarity of the criteria that makes the OSMM work. The OSMM can only function if the

indicators and the criteria that belong to them are easily understood and applied. If we look at the

indicators in more detail, the mature criteria become apparent.

OSMM v2.2 -25-


Indicator Immature Mature

Product

AgeThe project has just started. The stability of the developers group and need for the product are unclear.

The project has been active for some time. The project stability and need for the project are no longer issues.

LicensingNot fully described or clearly unsuitable for the product.

One of the ‘standard’ licences (www.opensource.org/licenses/)

Offers clear motives for choosing the license type, which is supported by the user community. Often allows both commercial and Open Source variants to co-exist.

Human

hierarchies

Original founder is lead developer and solely responsible. Development depends on a single person.

Large community, multiple leaders who coordinate. Separation of development and maintenance.

Selling points 12 Only enthusiasm.Commercial issues like security or maintainability.

Developer

communitySmall tight knit group.

Very active developers community, several hand-offs have taken place. Documented procedures to becoming a member.

Integration

Modularity

No modules, still one single product. Functionality is offered on a ‘take all or nothing’ basis.

Product has been separated into smaller pieces of functionality. Users can select which parts are required. Allows tailoring of the product to a particular situation.

Collaboration

with other

products

Not in focus yet. Product development is still firmly centred on core functionality.

Product is close to completion. Attention is shifting to linking the product to other products.

Standards

Uses propriety protocols or uses dead end technologies.

Uses current accepted protocols and models. Deals with issues surrounding standards, integration etc.

12 Open Source projects usually start because of some frustration with current offerings. This results in projects that

‘wanted to try it themselves’ or ‘want to become main product because the current ones are good not enough’.

OSMM v2.2 -26-


http://www.opensource.org/licenses/


Environment

User Community

Small group, possibly with a high proportion of ‘lurkers13’.

Large group that often has divided itself into sub-groups. Each group has a specific focus. Traffic in general is best described as high-volume.

Market

penetration

Few references, just local promotion. Low exposure is the reason the product isn’t wildly known.

Often mentioned by others (for example Gartner, ZDNet, Netcraft, IDC). Multiple cases of successful implementation across a range of companies. Well known.

Use – viewpoint integrator

Support

People will help, but you need to ask around and there will be little experience in some forms of use

Active user community with a patient attitude to newbies. Local commercial parties offer their services.

Proven

Very few references. Mostly individuals mentioning use within a corporate setting.

Verifiable references by companies over a period of time.

Architecture

Nothing worth mentioning. Basically there's more desire to code than to document the reason why.

The community has a vision, roadmap. These are maintained based on current events. How it is made is subject to the goals set.

Use – viewpoint consumer

Support

Limited, mainly technical support. Community assumes a level of IT proficiency, or foreign language or both.

Multiple languages are supported in the community. Commercial interest. Wide range of use are covered.

Proven

No clear information on how to comply with local laws / regulations. Lots of groundwork to do.

Either references by the community of commercial firms are provided for local usage.

Deployment There's some documentation, perhaps even a getting started, but it is not sufficient to drive an implementation

There are e-leanring options, on-site trainers can be hired or courses attended. Some might

13 People that are interested in using the product but show little inclination to contribute to it.

OSMM v2.2 -27-



plan. have certification programs.

2.The Score Card Approach

Because of the way the OSMM is set up, it is straightforward to score products and keep the results.

Ideally, once a year you should re-score a product. This will allow you to establish a repository of products

that meet your required score, or meet it for certain interest areas (for particular applications). As the

context scoring has been removed from the OSMM (and will resurface in the OPSP), each score can be

shared with anyone. In theory, the community could simply provide the score, making it a very organic

process. But in the interest of impartiality it might not be best to go with the self-score approach. The

OSMM defines a minimum level, so there's some incentive to up the ante and try and reach a higher score.

But this approach is entirely feasible if a form of verification could be established.

3.The criteria

The table below shows the scoring criteria for the indicators.

Product indicator Score: 1 Score: 3 Score: 5

Product

Age < 2 months 1-2 years > 3 years

Licensing Unclear / unknown

Clear (GPL, LGPL).

OSI approved.

Multiple options catering to the user’s requirements.

Human hierarchies Individual Club Organisation

Selling pointsIndividual enthusiasm

Group enthusiasm Business motives

Developer communityNot clear how to become a member

Becoming a member is possible, but requires initiative

Clearly documented procedures. Mentions skill and roles available. Use of group development tools is required.

Integration

Modularity One large application Some functionality is available

The design allows separate functions to be

OSMM v2.2 -28-



separately. Tailoring is limited.

used in a different context. Extensive customisation.

Collaboration with

other productsStand alone

Partial interaction (possibly by using certain protocols).

Incorporates accepted standards (for example: PAM)

Standards Propriety OutdatedLatest industry standards.

Environment

User Community Perhaps a mailing list

One or two moderated groups about all aspects of the product.

Multiple moderated groups, each one dealing with distinct aspects of the product. Users are active, forming unofficial groups and thinking up new initiatives

Market penetration Unknown A viable alternative Market leader


Support

Support by incidence at best, provided by developers with limited time.

Active user community ready to help, developers are quick to offer support for issues encountered.

Commercial support from the community sponsor or independent businesses. Extensive community support from users and developers, with an accessible knowledge base.

Proven

Limited mentioning of successful use. Unable to determine is this usable as a reference

At least 2 verifiable references, more evidence of use is to be found.

At least 3 verifiable references, one of which within the same country. Many mentions indicating the products is used satisfactorily

ArchitectureNo clear vision or view

A vision which influences the activities. Not actively maintained

Vision and supporting architecutre is available. It is revisted and update periodically.

Use – viewpoint consumerSupport Only from the

community, single language, single culture, need to ask

Commercial parties available but mostly small firms no located close

Local commercial support available, choice for at least 2 parties that exist for at least 2 years.

OSMM v2.2 -29-



by.

ProvenNo mention of verifiable use.

References can be found, limited locally. Service partner available for ensuring compliance.

At least one verifiable reference of an implementation with the same legal context. Minimum of 2 ISV that offer service contracts in this setting.

Deployment

Virtually no documentation. None in the own language. No training options.

User community support, list of HowTo's. Some introductary training material.

Active and extensive knowledge base. Localisation in at least 3 languages. Trainers or training courses available. Companies offering deployment services available.

Because some indicators cannot be measured in a purely numerical sense; these scores should be

determined by a group of experts who have demonstrated knowledge of Open Source and have worked with

similar products. Because of the use of a group, the score cannot be set by one single person, ensuring a

more objective score.

If an indicator isn’t applicable for a particular product, the score is set to 3. Because the OSMM advised

to always use a threshold value of 3+, setting the score to three ensures that this indicator does not affect the

outcome in a positive or negative way. The determination of maturity is therefore always controlled by the

indicators receiving a below or above 3 score. This maturity threshold is a cut-off point; below this cut-off

maturity is not enough to qualify for further selection.

4.Consideration to criteria expansion

Over the years, whilst looking at the original OSMM and being involved in many discussions, one

subject that always surfaces is the discussion on indicators. Many new indicators have been suggested,

almost none made it into the model. Why is this? Well, some indicators are measuring the same thing, but

using different criteria. When you score many products, you see that these indicators almost always score

equally good or bad. This slants the model and yields incorrect results. Another indicator might not actually

be measuring maturity, but something else, in the authors experience, usually functionality. Whenever

thinking of adding more indicators to the OSMM it is wise to keep this in mind.

OSMM v2.2 -30-


The aim of the OSMM is not to find as many indicators as possible, but actually the reverse, as few

as possible yet still providing a reliable outcome. Less indicators make it easier to score, the easier it is to

score the more it will be done. The more it is done, the greater the intricate ways of how Open Source

products are developed using collaborative, organic communities are understood. Once you understand the

nature of Open Source, you will find less reasons to block their use and more reasons for wanting to benefit

from them. As you learn to participate in the communities (usually as user at first, but over time this might

expand), you will not only be strengthening how you get value from the community, but also will be

contributing and providing value to others.

5.The importance of keeping up to date

One of the fundamental properties of Open Source products is that they exhibit an irregular

improvement ‘road map’. A primary reason for this phenomenon is that improvements are mostly requested,

the user community has a requirement that is addressed. With proprietary software a new version also has an

economic motive; it generates income.

This irregular development path that is native to Open Source products causes some products to

improve at a very high rate, whereas the products competitors could show a much more relaxed approach.

The developer and user communities are responsible for these differences. Because of this variance updating

the maturity model on a regular basis is imperative. Others are comfortable with a pre-defined release

schedule. Canonical's Ubuntu is prime example of this, with 2 release a year, one in April, one in October.

OSMM v2.2 -31-


. A detailed example

. An overview

Using the previously described indicators the maturity of Open

Source products can be determined. As the score cards can be drawn up

at any time, your IT partner or your own organisation might have several

of the more interesting products already scored. The advantage of this

approach is that you can choose to be helped, or separate the scoring from

the choosing.

The indicators receive a score valued between one and five. One is poor,

five is excellent and 3 is average. All the scores are summed to produce

the maturity score. In the OSMM the threshold is set to mean anything

below 3 is a risk that might be too high for most. At 3 the product is not

great, but no one day fly either. Above 3 is considered so mature it should

not present a special risk. Below three comes with the recommendation to

seriously examine what you are getting into. You can also look at the

maturity score per interest area. This could be interesting if a particular

area is of special interest. And even when the overall score is >= 3, a score

of < 3 for any interest area, or even an individual question could point you

towards specific risks the product could present. If you ever find a product

scoring a 5 across the board, you'd be hard pressed to find any close

source company less risky.

A change from the original OSMM is the dropping of the functional

measurement using application indicators. This will be handled by creating

the OPSP (Open Product Selection Process) in which initially the same

measurement as was provided by the OSMM will be placed. The authors

think is better because of the difference in development. There is no open

documented way in which to select products functionally, many firms

claim to offer the service, without the transparency. The OPSP will create

OSMM v2.2 -32-


Final evaluation

Evaluating OSMM v2and OPSP results

Applying the OPSP tothe short list

Short listing the products based on

the score cards

Applying the OSSM v2to the pre-selection

Product research andpre-selection

a level playing field for all, and one that can be verified to neither favour

open or close source products and simply determine a 'best fit' with the

dynamics of how the product will be used.

A mandatory part of the OSMM process is the feedback phase, which should be conducted in the

final evaluation. When the results are not as expected, either the model is flawed, hard to apply correctly or

not clearly understood. It is clear that the OSMM can only work if the results are to be trusted. Just as with

the first OSMM, the OSMM v2 is also tuned to ensure its accuracy. The tuning of the OSMM v2 is done by

Open Source consultants, such as those from Cognizant Technology Solutions. As with anything open,

feedback on potential improvements is an important contributor to the sustained accuracy of the OSMM14.

. In detail

In this example we’ll compare two non-existing products, A and B. We'll walk through the indicators

and discuss the results as we plot the interest areas of the OSMM v2. We have selected the viewpoint

integrator.

Indicator Product A Product B

Product

Age 1 3

Licensing 2 2

Human hierarchies 1 4

Selling points 2 3

Developer community 2 3

Integration

Modularity 1 2

Collaboration with other

products 2 2

Standards 2 4


Support 2 3

Proven 4 3

Architecture 3 4

Environment

14 Any comments for the OSMM and OPSP can be submitted at http://open.widdows.eu for now.

OSMM v2.2 -33-


http://open.widdows.eu/

User community 2 4

Market penetration 3 2

TOTAL 27 39

Maturity score 2 3

The table allows us to determine a score for each group of indicators. This allows us to compare

products on a group basis, for this example we can draw this graph:

Clearly both products score well on use, but both products fall short when it comes to integration.

And product A doesn't score very well when the product intrinsic aspects are looked at. Both are equally

mature

In more detail, this example shows that according to the product indicators product A is less mature

than product B. This means that OSMM favours product B for use over product A. The OSMM has a

threshold, below which the use of the product in a professional setting is not advised. If a product fails to

meet the minimum maturity criteria this will be explained in detail, together with the risks and a ‘maturity

OSMM v2.2 -34-


Product

Integration

Use

Environment 0

2

4

Score per group

Product A

Product B

prediction’ (i.e. an assessment of the way in which the maturity of this product will develop in the next 6

months based on the knowledge the OSMM user has). Product A fails to meet the threshold, Product B

does, but looking at the plot, it achieves this by falling short in the interest areas Environment and

Integration, but meeting the threshold comfortably in the interest areas Use and Product.

By looking at the graph, the issue areas are easily identified. The OSMM identifies the above average

risk areas, allowing you to choose to either mitigate, or choose another. For the products that do not meet

the threshold, the areas of growth are clearly marked, allowing for a focussed monitoring of these interest

areas. If the product is deemed a high potential, the areas most in need of maturing are shown. It is easier to

check to see if the community is concerned with the same issues, of find this not relevant.

However mature a product is, it must be mentioned that it should also be suitable for the task at hand.

If you need something that floats, it's ability to fly is of little help. In the previous version of the OSMM,

this was the second stage of the mode. In version 2, this has been moved to the OPSP. The OPSP is

applicable to both Open Source and closed source products, whereas the the OSMM is to examine Open

Source only. This explains why the OPSP is to be separate, to ensure Open Source is treated as a proper

alternative, there is every reason to treat Open Source and closed source equal as much as we can. Where

we can't, the Closed Source products can be assessed with a tool that does understand the dynamics of Open

Source product development. The OSMM v2 is such a tool.

OSMM v2.2 -35-


. Evaluation, the secret of success

As with anything that measures, calibration is important. The IT market changes strongly from year

to year; with new ways to use IT in the workplace being discovered continuously. The IT products also

change, just as the idea of using Open Source product wasn’t really considered to be realistic until recently.

Changes in the political, economic climate and recent changes to the licensing policy of some companies

have focussed the attention on Open Source products as a viable alternative. Independent companies have

conducted extensive research and concluded that for quite a few IT solutions Open Source offers a

worthwhile alternative. The OSMM provides a way to assess this alternative on its own merits.

To continue to profit from the advantages that the OSMM offers the continuous calibration of the

indicators is essential. If you choose to use the scorecard approach, continuous checking of product

indicators is advised to ensure they remain accurate. This principle is also applied to the product profiles of

previously scored products. When a product changes (such as a new release, new functionality, different

licensing etc...) the product should be re-scored.

The OSMM can score products independent of use, but to measure the suitability it needs to be

evaluated by using something like the OPSP. Both the OSMM and the OPSP are free to be used by anyone,

but akin to cooking, even with the same ingredients, those cooks that know the dish well should yield better

results. So there is always the option of asking specialists for advice.

. Acknowledgements

The authors want for thank Cognizant Technology Solutions B.V. for providing the opportunity to keep

growing and strengthening the Open Source Maturity Model, and Capsis B.V. for their continued interest and

support.

The authors want to thank Ordina ICT B.V. for partly sponsoring the effort that has gone into making

version 2. For the first time there was room inside office hours as well to work on this exciting and proven

model. In particular the Open Xcellence group that helped with the review of the 2nd version. Also a big

thank you to Capsis B.V. for their support in allowing the authors to work together once again and make the

second version of the OSMM a more open and collaborative effort.

OSMM v2.2 -36-


The authors also want to acknowledge the efforts Capgemini has shown over the years is maintaining

access to the original OSMM and the manner in which it has used it internally for years for helping

customers.

Also a word of thanks to Imran William Smith for reading through and suggesting some corrections

provided for the first OSMM.

OSMM v2.2 -37-


. OSMM – License15

Creative Commons Attribution-NoDerivatives 4.0 International Public License

By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms

and conditions of this Creative Commons Attribution-NoDerivatives 4.0 International Public License

("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the

Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants

You such rights in consideration of benefits the Licensor receives from making the Licensed Material

available under these terms and conditions.

Section 1 – Definitions.

a) Adapted Material means material subject to Copyright and Similar Rights that is derived from or

based upon the Licensed Material and in which the Licensed Material is translated, altered,

arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright

and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed

Material is a musical work, performance, or sound recording, Adapted Material is always produced

where the Licensed Material is synched in timed relation with a moving image.

b) Copyright and Similar Rights means copyright and/or similar rights closely related to copyright

including, without limitation, performance, broadcast, sound recording, and Sui Generis Database

Rights, without regard to how the rights are labeled or categorized. For purposes of this Public

License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.

c) Effective Technological Measures means those measures that, in the absence of proper authority,

may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright

Treaty adopted on December 20, 1996, and/or similar international agreements.

d) Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation

to Copyright and Similar Rights that applies to Your use of the Licensed Material.

e) Licensed Material means the artistic or literary work, database, or other material to which the

Licensor applied this Public License.

15 This is a copy of the legel text found here: http://creativecommons.org/licenses/by-nd/4.0/legalcode

OSMM v2.2 -38-


f) Licensed Rights means the rights granted to You subject to the terms and conditions of this Public

License, which are limited to all Copyright and Similar Rights that apply to Your use of the

Licensed Material and that the Licensor has authority to license.

g) Licensor means the individual(s) or entity(ies) granting rights under this Public License.

h) Share means to provide material to the public by any means or process that requires permission

under the Licensed Rights, such as reproduction, public display, public performance, distribution,

dissemination, communication, or importation, and to make material available to the public

including in ways that members of the public may access the material from a place and at a time

individually chosen by them.

i) Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC

of the European Parliament and of the Council of 11 March 1996 on the legal protection of

databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in

the world.

j) You means the individual or entity exercising the Licensed Rights under this Public License. Your

has a corresponding meaning.

Section 2 – Scope.

a) License grant.

1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a

worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the

Licensed Rights in the Licensed Material to:

A) reproduce and Share the Licensed Material, in whole or in part; and

B) produce and reproduce, but not Share, Adapted Material.

2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations

apply to Your use, this Public License does not apply, and You do not need to comply with its

terms and conditions.

3. Term. The term of this Public License is specified in Section 6(a).

4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise

the Licensed Rights in all media and formats whether now known or hereafter created, and to

make technical modifications necessary to do so. The Licensor waives and/or agrees not to

OSMM v2.2 -39-


assert any right or authority to forbid You from making technical modifications necessary to

exercise the Licensed Rights, including technical modifications necessary to circumvent

Effective Technological Measures. For purposes of this Public License, simply making

modifications authorized by this Section 2(a)(4) never produces Adapted Material.

5. Downstream recipients.

A) Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material

automatically receives an offer from the Licensor to exercise the Licensed Rights under the

terms and conditions of this Public License.

B) No downstream restrictions. You may not offer or impose any additional or different terms

or conditions on, or apply any Effective Technological Measures to, the Licensed Material if

doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.

6. No endorsement. Nothing in this Public License constitutes or may be construed as permission

to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or

sponsored, endorsed, or granted official status by, the Licensor or others designated to receive

attribution as provided in Section 3(a)(1)(A)(i).

b) Other rights.

1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are

publicity, privacy, and/or other similar personality rights; however, to the extent possible, the

Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited

extent necessary to allow You to exercise the Licensed Rights, but not otherwise.

2. Patent and trademark rights are not licensed under this Public License.

3. To the extent possible, the Licensor waives any right to collect royalties from You for the

exercise of the Licensed Rights, whether directly or through a collecting society under any

voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor

expressly reserves any right to collect such royalties.

Section 3 – License Conditions.

Your exercise of the Licensed Rights is expressly made subject to the following conditions.

OSMM v2.2 -40-


a) Attribution.

1. If You Share the Licensed Material, You must:

A) retain the following if it is supplied by the Licensor with the Licensed Material:

i. identification of the creator(s) of the Licensed Material and any others designated to

receive attribution, in any reasonable manner requested by the Licensor (including

by pseudonym if designated);

ii. a copyright notice;

iii. a notice that refers to this Public License;

iv. a notice that refers to the disclaimer of warranties;

v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable;

B) indicate if You modified the Licensed Material and retain an indication of any previous

modifications; and

C) indicate the Licensed Material is licensed under this Public License, and include the text

of, or the URI or hyperlink to, this Public License.

For the avoidance of doubt, You do not have permission under this Public License to Share

Adapted Material.

2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the

medium, means, and context in which You Share the Licensed Material. For example, it

may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource

that includes the required information.

3. If requested by the Licensor, You must remove any of the information required by Section

3(a)(1)(A) to the extent reasonably practicable.

Section 4 – Sui Generis Database Rights.

Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the

Licensed Material:

OSMM v2.2 -41-


a) for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and

Share all or a substantial portion of the contents of the database, provided You do not Share Adapted

Material;

b) if You include all or a substantial portion of the database contents in a database in which You have

Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but

not its individual contents) is Adapted Material; and

c) You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the

contents of the database.

For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under

this Public License where the Licensed Rights include other Copyright and Similar Rights.

Section 5 – Disclaimer of Warranties and Limitation of Liability.

a) Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers

the Licensed Material as-is and as-available, and makes no representations or warranties of any kind

concerning the Licensed Material, whether express, implied, statutory, or other. This includes,

without limitation, warranties of title, merchantability, fitness for a particular purpose, non-

infringement, absence of latent or other defects, accuracy, or the presence or absence of errors,

whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in

part, this disclaimer may not apply to You.

b) To the extent possible, in no event will the Licensor be liable to You on any legal theory (including,

without limitation, negligence) or otherwise for any direct, special, indirect, incidental,

consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this

Public License or use of the Licensed Material, even if the Licensor has been advised of the

possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed

in full or in part, this limitation may not apply to You.

c) The disclaimer of warranties and limitation of liability provided above shall be interpreted in a

manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of

all liability.

OSMM v2.2 -42-


Section 6 – Term and Termination.

a) This Public License applies for the term of the Copyright and Similar Rights licensed here.

However, if You fail to comply with this Public License, then Your rights under this Public License

terminate automatically.

b) Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates:

1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your

discovery of the violation; or

2. upon express reinstatement by the Licensor.

For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek

remedies for Your violations of this Public License.

c) For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms

or conditions or stop distributing the Licensed Material at any time; however, doing so will not

terminate this Public License.

d) Sections 1, 5, 6, 7, and 8 survive termination of this Public License.

Section 7 – Other Terms and Conditions.

a) The Licensor shall not be bound by any additional or different terms or conditions communicated by

You unless expressly agreed.

b) Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein

are separate from and independent of the terms and conditions of this Public License.

Section 8 – Interpretation.

a) For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce,

limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made

without permission under this Public License.

b) To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be

automatically reformed to the minimum extent necessary to make it enforceable. If the provision

cannot be reformed, it shall be severed from this Public License without affecting the enforceability

of the remaining terms and conditions.

OSMM v2.2 -43-


c) No term or condition of this Public License will be waived and no failure to comply consented to

unless expressly agreed to by the Licensor.

d) Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of,

any privileges and immunities that apply to the Licensor or You, including from the legal processes

of any jurisdiction or authority.

OSMM v2.2 -44-


Documents

Open Soure Maturity Model v2 · 2018-03-03 · Capgemini. 2. The document is reproduced in full -or- a reference to the original ... 10 .WHAT DOES MATURITY ... market dominance etc