📖 The importance of standards for your business

4 minute read

This is an excerpt from my upcoming corporate open source strategy book, being published by Pragmatic Bookshelf in 2021. All book excerpt content is early in the development process and therefore unedited; the errors are mine alone (and will be fixed before publishing 😉).


The first chapter of the book lays the foundation for what’s to come. This includes not only the free/open source software origin stories but also why and how these things are so vital for businesses.

One of the most important elements to FOSS business value is that it’s standardised. This enables confidence, trust, and interoperability.

Without standards, your company would have a difficult time doing business. Let’s say you’re in the grain business, packaging and distributing rice to stores for consumers to buy and take home to feed their families. There are a lot of standards that ensure that you’re able to operate without having to second-guess everything you buy and sell. There are standards for the quality of rice, whether it’s grown using organic methods, and precisely what mass of rice makes up a kilogram. There are organisations that exist solely to create these standards, and others dedicated to reviewing and certifying that the standards are being followed. Both types of organisation do this work so your company doesn’t have to and is therefore freed up to literally go about its business.

Now what would happen if, somewhere in your rice company’s supply chain, there were a deviation from these standards? Your company could be paying a premium for wholesale organic rice then receiving cheaper rice grown using conventional methods or, even worse, it may be paying for a certain number of pounds of rice but then receiving the same number but of kilograms instead (a quantity less than half what you were expecting), because the wholesaler is working under a different definition of “pound” than you are. [[ed note: yes, I know this is backwards; it’s already flagged for fixing in the final text; like I said above, this is unedited content]] Imagine the chaos that would ensue in your business if your company couldn’t rely on standards. Standards enable business to operate and smooth communication by creating a shared and trusted language and understanding.

While it doesn’t use this terminology, by having a single, standard specification for what’s required for software to be open source, what the Open Source Initiative (OSI) has created and maintains with the Open Source Definition (OSD) is a standard, making the OSI a standards body. Like other standards, this one is vital for the operations of any business that uses or creates software (which is to say, nearly all of them). When your company receives software that bears the label “open source,” you know that while there may be some responsibilities to be aware of in the license, you now have a firm grounding in generally what to expect from that software. You know that it won’t prevent your company from using the software in certain situations, that if needed your company can modify the software to support its business needs, and that it can even sell the software if that’s what makes sense for its business model. It knows these things because the software is provided under a license that the OSI has certified obeys all ten criteria in the Open Source Definition, including OSD 3 (requiring the ability to create derived works) and OSD 6 (prohibiting discrimination against any fields of endeavour).

Imagine if your company received and starting using software that claimed to be “open source” but was operating under a different definition. Perhaps the provider of the software has strong objections to wheat, so they modify an otherwise OSI-approved license to include the stipulation that the software cannot be used in any application that supports or promotes the use or promulgation of any sort of wheat or wheat products. If the software is ever used for that, the perpetrator must pay the software provider 50% of their income from the past year. Your grain company, believing the software must be obeying the OSD because it’s labeled “open source,” proceeds to use the software to build the logic software for its grain-bagging machine. If that machine is used to bag wheat, the company has violated the license and now owes a great deal of money.

It may seem contrived, but unfortunately this sort of thing is happening more often of late: software claiming the “open source” label being released under licenses that violate the OSD in one or several ways. This practice is eroding trust in the “open source” standard and making it considerably more difficult for businesses to operate.

Shared and agreed-upon definitions ensure we can all communicate and interact efficiently. Imagine how complicated matters could be if hardware and appliance manufacturers provided interfaces named “USB-C” but each interpreted that differently. None of the cables you have would work on different devices. It would prove impossible to operate, as you constantly second guess and need to verify what you’ve been told. The same business risk holds true for any violated standard, including open source.


The excerpt content is copyright © 2021 The Pragmatic Programmers, LLC and used with permission. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher.

All other content of the post is Copyright VM Brasseur and licensed under CC BY-SA.