The request for the definition of a "policy on Open Source"  gets frequently passed to the Enterprise Architecture team. So some thought about Policy in general and open source in particular.

• Policy (noun) (from OED)

plans, strategy, proposed action, blueprint, approach, scheme, strategem, programme, schedule, code, system, guidelines, intentions, notions, theory, line, position, stance, attitude

practice, custom, procedure, want, way, tack, routine, matter of course, style, pattern, convention, mode, rule

All sound and typically established with good intentions, though politicians are masters at siting policy as way of evading pointed questions on particular situtions.

The simple truth is that if you want a "policy" to be successful, especially if it is counter to current practice, then you will need to make an investment.

In the context of "Open Source" this means more than just using open source software, it means participating.  This will require investment in time, people and money. If you are going to invest, then you should have some objectives and expectation of the results. So lets lay out some simple expectations and objectives for use of Open Source within corporate IT.

Misconceptions

• Open Source is about saving money on licensing costs

Reality

• Over the life of a software solution licensing might be 10% of TCO, largest cost is on ongoing SI and enhancement (change !!)
• There is no difference in cost of configuration vs. cost of “coding” (and many Open Source developed packages are highly configurable in any case)

So why move to Open Source

• Software development is not a support function, but critical enabler for business
• Open Source projects provide a rich skills pool to drawn on as they are driven by highly skilled and motivated people and attract some of best systems development talent
• Open Source and "free" software (free as per fsf) have visible data schemas, allowing greater data visibility which is essential to achieve agility
• Open Source solutions are mostly driven by operational needs and so are rooted in clear use cases and developed incrementally around these
• Open Source solutions have functionality as good as proprietary solutions
• The community functions as shared interest / collaboration environment, a functional that that previously achieved by vendor product management teams

So

• You and your organistion will benefit by being more responsive and being better at the job than your competitors
• Adoption of Open Source should be focused on people, talent and skills, not saving money on licensing costs

Remember

• Many open source projects have been going for many years and have code and knowledge base that are equivalent to proprietry solutions
• Open Source projects are typically populated by participants who are doing their work as paid professionals and many large ICT companies have made large investments in Open Source for the same reasons outlined above

Sign posts for success

• Is ownership of software function close to business outcome owner ?
• Or conversely how many layers are there from definition of intent to delivery of digital outcome ?
• What is the ratio of evangalists and advisors on agile and open source vs the number of active participants ?
• Are you delegating definition of needs and delivery against these to supplier or are your team active particpants ?
• Are you and your supplier partner both activitely leveraging the same up stream open source projects ?
• Can the team clearly articulate the desired objective and understand how this will be achieved (a sharp focus on particular use case is illustrative of this) ?
• Are you in the Cathedral or the Bazaar :-) ?

Dangers & Risks

Yes there are dangers and risks with Open Source and some of the most commonly articulated are around security and unfettered technology proliferation.

These are valid concerns but the way to counter these is not to stop use of open source. Rather estabish the right life cycle management processes like: automatic and continuous  security scanning and comprehensive automated functional and performance testing.

Apologies for introduction of another digital buzzword towards the end of this note, but DevOps should be used to counter these risks. In bringing IT closer to business  the number one focus of DevOps should be to protect operational systems and ensure that there is on going ownership of the operational outcome by the development team.

Each of: Digital, Open Source adoption and DevOps bring accoutability closer to the owning party.

And back to Policy, in writing one try to reduce the gap from policy to result and ensure that there are clear goals and expectations around the policy.

References:

Policy - Oxford English Dictionary  (transcribed from iPhone Edition ;-) )

Open Source - has its roots in "Free Software Foundation" established by Richard Stallman

10% of TCO - based on authors analysis (as leader of Enterprise Architecture team) of large investment in enterprise systems for large telco over 5 years

The Catheral and the Bazaar - the open source musing on open source by Eric Steven Raymond

NOTE 1: In writing this piece I was wondering if this should be in the "Industry Pages" or the "Just Enough Architecture" pages, as both Open Source and Digital represent trends in "Industry" as well as a in how we approach "Architecture"