It is clear that, where there is sufficient common interest, an Open Source philosophy is capable of providing high quality solutions. There are many examples where the high number, and depth of expertise, of reviewers has clearly demonstrated development of high reliability solutions.

The problem is however that these solutions are then entwined with licencing conditions which aim to maintain that ‘freedom’ of information (and sources) such that opportunities for developing commercial product that contains components that are open source are essentially denied because the additional developments have then to be disclosed, rendering no commercial advantage in such endeavours.

It is however possible to make a commercial business out of value-added activities around Open Source (e.g. Linux packagers like RedHat).

From a sourcing point-of-view then, what are the conditions under which you should consider the use of Open Source? If you can collect no revenue from your bespoke developments once including, or a development of, Open Source components, then what other rationale might suggest you join in such endeavours?

In Eric S Raymond’s book “The Cathedral and the Bazaar” he alludes to a number of business opportunities, some of these are paraphrased here:

• You could build an open-source tool (a ‘loss-leader’ approach) that enables people to easily access your paid-for service.
• You can bundle in software that provides the user access to the functionality of your platform, when you are in the business of selling platforms (e.g. microcontrollers, or even Silicon IP) but not developing software. This becomes significant for commodity platforms who wish to separate their customers from the concerns of component obsolescence.
• You can contribute to solutions that may be imposed as standards and are therefore not product differentiators, such as communication protocol stacks, and in doing so reduce your risk.
• You can offer a transition from closed-source to open source as an ESCROW policy where the customer requires long-term accessibility, including potentially through the derogation of functionality on which he depends, derogation of the product, or supplier business collapse.
• You can influence open-source tooling to provide features that would only otherwise be available in expensive commercial solutions e.g. Configuration Management, Version Management and Change Control, thus obviating the need for large capital investments.

Raymond identifies the major criteria for going (and by implication using – as this forces you to “go”) Open Source as where:

a)       Reliability, Stability and Scalability are critical

b)       Correctness of Design or Implementation are not readily verified other than by independent peer review

c)       When the software becomes a business-critical capital good (i.e. control of the business for customer)

d)       Establishes or enables a common computing or communication infrastructure

e)       Key methods (or their functional equivalents) are part of common engineering knowledge

“Open-source makes least sense for companies who have unique possession of a value-generating software technology, which is insensitive to failure, can readily be verified by means other than independent review, is not business-critical and which would not have its value substantially increased by network effects or ubiquity.”

Although with open source an individual, other than the product champion (‘owner’ in as much as he caretakes the development), has little direct authority on the product and its evolution, he may significantly influence development by offering suggestions for change. Depending on the capability and acceptability of the individual (or group) contributor, this could range from suggestions on potential features, to ‘patch’ proposals that offer an easy route to adding functionality to the implementation and its documentation.

The tooling, rather than delivered product, model offers many more freedoms to use open sources as seed material for bespoke non-commercial tool or method developments, but has as many pitfalls, as once ‘branched’ from the root-stock and its development community, so forfeits the maintenance, support and evolution.

___________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.     ___________________________________________________________________________

 

So, you have decided it is not profitable to develop some of your product yourself, but to get those components developed in the supply chain… but Where do you go? How do you know if they are right for you? Can you trust them?

Well hopefully in making the decision to not do it all yourself, but to find a partner or supplier, you have already benchmarked your own capability with the capabilities that exist elsewhere, so you have a source and an initial assessment of the potential suppliers. If not you really need to go back and re-appraise the decision on Make/Buy!

Typically that initial source of supplier information is from word of mouth, a trade body membership catalogue, reports from technology analysts or researchers (e.g. Gartner, Forrester, IDC, Ovum, Frost & Sullivan).

For most of the ‘physical industries’ (e.g. mechanical manufacturing) location of the supplier is significant to ensure a consistent logistical delivery, minimum transport costs etc. With software and an interconnected world, at first sight, this is not an obvious priority.  My personal experience however is that ‘accessibility’ of the supplier will determine the amount of time that you will spend on oversight and the supplier relationship, especially when there is a need for ‘intervention’.

Even for software supply, a nice glossy sales brochure, some historic glowing testimonials and sample CVs doesn’t give you the same information that you will get as a seasoned professional in being invited for a visit into their development offices. Be prepared to withhold judgement on the sales ‘spin’ until you know the details of what you will be getting.

Safety, Security and Quality are ‘cultures’ which all employees have to live… and the supplier’s ethos can usually be picked up from a visit to the development offices, much like you would when visiting a mechanical workshop; If tools and consumables are not neatly organised, put away after use and obviously well maintained – you need to be going somewhere else! If there is an absence of fire extinguishers, or access control mechanisms, it will be self-evident that these traits are not cultural.

With software developers, if a randomly selected engineer cannot tell you in detail how he interacts with the change control and configuration management processes, without resorting to the manuals, then walk away.

For any ongoing project, the software manager and project manager should know who their key technical players are (and not just the senior people, the real influencers); what the significant aspects of the product architecture are; the complex or risky areas of the development and what they are doing to understand them; and be at ease discussing the sort of metrics that indicate quality components are being generated on time e.g. the number of iterations of a component (from version control), where those evolutions were triggered (i.e. the types of error that escaped, where they were detected and resolved); how much effort is being consumed, how that relates to the plan, estimates and the consumption of contingencies.

You are going to want the same information made available to you, on your project, to give you the confidence they are conveying. If the information you need is not available, then you can easily imagine you will be asking for it later, once a crisis is looming or already impacted!

If it’s a small supplier, where all the design aspects are in 1 person’s head, who is working vast numbers of hours, including weekends… then irrespective of the heroic efforts… it might imply fragility that you cannot depend on.

Ideally you need a supplier who shares the same culture and ethos with regards the attributes you espouse, after all your product, like a chain and weakest link, will typically demonstrate the quality attributes of the poorest component.

You don’t want to be micro-managing your supplier, you want him to have the level of information to resolve his own problems and be a good supplier, whilst appraising you of risks that you need to jointly manage. Expect to need to invest and develop some of these traits in your supplier, so that they deliver what you need.

Ideal commercial arrangements should, like managing children, incentivise and reward correct behaviour, and admonish wrong behaviour without being punitive. Manage not only the development within the supplier, but your rights to the work, to give you the flexibility and portability you need, in the same way that the Make/Buy decision will have informed you about the level of dependence and exposure protection you need. In my experience, escalation to punitive legal clauses means your product is lost!

___________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.     ___________________________________________________________________________

 

In this day and age it is key that a business spends its precious resources on things that add significant value to the product. In software developments it is all too easy to assume that you need to develop all of the components from scratch and with it the opportunity cost of those components.

There are often many alternative sources for those components, some come with a licensing cost, or at least restrictions, some with the cost of using a more suitably qualified partner… and almost all come with an overhead of assessing the relationship you will need with the supplier or an assurance of the quality of the acquired product to support your business.

The decision on ‘do it yourself’ or find some other source, should not be overly emotive. There are simple, and very visual, techniques that will help you through the ‘postioning’ and ‘value’ judgements that are useful with both technical and senior management audiences. Such techniques are more fully described here. https://sofintsys.com/papers/Make%20or%20Buy.pdf

The Make/Buy decisions will be swayed by the strategic intentions of the company, its expectation about what knowledge it needs to nurture and grow, or what is ‘commodity’ experience that is openly and cheaply available.. and a pragmatic understanding of current capability and ability to immediately embark on some endeavours without more expert support.

In software, there are many specialist field which may not be matched by own capability e.g. the deeply embedded skills that have an electronic bias and register-level competence with the devices, hardware programmable devices and real-time performance; the application programmers who work to a well-defined API and rarely have to worry about the platform; the user-interface specialists, who understand the ergonomics, physiology and responses to fatigue of repetition, error-prone operation due to layout or colour use. It is rare that individual engineers are able to be highly skilled in more than one of these areas, although it may be perfectly possible for them to create solutions!

Once you have made the decision to acquire software (whether as a commodity purchase, or as a commissioned component or product) you could do worse than look at these checklists. https://sofintsys.com/papers/Software%20Acquisition.pdf

These can help you set out an objective set of questions so that all suppliers can be assessed equably. This can be of significant importance once such as ‘selection’ process is passed off to a commercial or purchasing team, as it enable an appropriate focus to be placed that will still need appropriate technical judgement of the answers to differentiate the most appropriate supplier… whilst keeping the engineers at arms length from the ‘price’ negotiation, or individual supplier bias… attractive in many large commercial organisations.

Whatever your selections, the necessity of assessing current skills, must be a combination of judgement of historic capability and the intention to support skill development with necessary training, the selection of highly productive tools, the protection of the value and intellectual property that is created and a clear connection to the business of market position, the technical and commercial offerings that match sales opportunities.

These attributes must be clear for both your internal team, but also the measures by which your designated suppliers and partners have to be judged as successful.

___________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.     ___________________________________________________________________________