The Wrong Way to Use Open Source

The glass is less than half full, and that is worrying. One of the focus areas in the 2022 State of Data Science report was enterprise adoption of open source. On every important metric, less than half the respondents gave the answer I was hoping for. For example, “We use a managed repository” got 43%, and “We use a vulnerability scanner” got 36%.

With such a low security maturity, it is obvious that the Log4j debacle and recent hacktivism has dented open source adoption. 40% report scaling back the use of open source in the past year.

Open Source gives you transparency that proprietary software doesn’t. That means you have the ability to verify that it works as promised instead of simply trusting vendor promises. But if you don’t make use of this transparency and instead simply download something because it’s free, you are setting yourself up for problems. Is your organization found in the more than half-empty part of the glass?

You Need an Agile End Result More Than an Agile Process

An agile development process is not important. An agile end result is. If your organization realizes a benefit from an agile methodology, that only helps you during the relatively short development process. But if you build something that can easily be re-configured and changed, that benefits you for the year or decades that you are running the system.

You would think that a digital billboard would be agile. The whole point is that it can display whatever you want. But German advertisers and shops have just realized that their display screens have very narrow agility. A new law requires these energy-guzzling billboards to be switched off at night to save electricity. It turns out that all the devices were built on the assumption that they would always be on, and they do not take kindly to store employees simply yanking the power cord when they go home.

To achieve agility in your products and systems, you need to avoid hard-wiring your assumptions into them. The only thing you can safely assume is that everything will eventually have to be changed.

What do you incentivize?

You get what you reward. Twitter decided to primarily reward user growth, and things went downhill from there. Recently, their head of security quit. Then he filed a whistleblower complaint with the authorities, complaining that Twitter’s security is bad and not getting better. Now there is likely to be a very interesting congressional hearing.

White-hat hacker Peiter Zatko (aka “Mudge”) was hired after a 2020 security breach but could not implement the changes he felt were necessary to fight spam and automated bots. The reason is the incentive structure at Twitter.

You see, Twitter management bonuses are based on user growth. There is no bonus for reducing spam or automated bots. You get what you reward, with no exception. You can reward with money, perks, promotions, or other recognition, but you have to incentivize the behavior you want. If all your incentives are based on quantity and not quality, you will get ever-increasing quantity and ever-decreasing quality.

Do You Want Fancy, Cheap, or Usable?

Do you prefer fancy, cheap, or useful? Car manufacturers have found that touchscreens look fancy and are cheaper than physical buttons. That’s why modern cars have touchscreens and no buttons. I prefer buttons, and science is on my side. A survey shows that it is almost twice as fast to perform common car tasks with buttons than with a touchscreen.

Unfortunately, a car is not required to be easy to operate. Aircraft cockpits, on the other hand, are full of physical buttons. An aircraft manufacturer accepts the extra cost of physical controls to provide an optimal user experience for the pilot.

Marketing wants fancy. Finance wants cheap. User Experience wants usability. Who has the last word on product design in your organization?

The Tolstoy Principle in Action

This is what failure looks like: 50% one-star reviews. The other half is five-star reviews. Assuming these are not all from the app developers themselves, the app apparently can work. It just didn’t work for me, nor for many others.

I call this the Tolstoy principle: All successful apps are alike; each unsuccessful app is unsuccessful in its own way. The end-user does not care that 98% of your back-end infrastructure is running. They care that they can complete their task. And if one critical component fails, your app is a failure. Like this one from my local supermarket chain.

When you build systems, is all the attention lavished on a cool front-end app? Unsexy back-end services are equally important.

Are You Monitoring Your Automated Systems?

It is hard to anticipate the real world. I’m sure the wet concrete on the road in Japan looked just like solid ground to the delivery robot. Consequently, it happily trundled into the urban swamp and got stuck. The story does not report whether the delivery company managed to get their robot out before the concrete hardened…

This is why you need careful monitoring of all the fully automated systems you are deploying. The first line of defense is automated metrics and their normal interval. For a delivery robot, the distance covered over a minute should be greater than zero and less than 270 (if you have limited the robot to e.g. 10 mph). The second line of defense consists of humans who will evaluate the alarms and take appropriate action. The third line of defense are developers who will fix the software and the alarms.

Too many automated systems are simply unleashed and depend on customers to detect that something is wrong and complain. You want to figure out you have a problem before the image of your robot encased in concrete starts trending on Twitter.

Are you Releasing Sub-Standard Systems?

Out of a sample of 5,000 apps, 80% did not live up to a reasonable standard. Are you releasing sub-standard apps or systems?

A company the reviews healthcare apps for the UK National Health Service found many bad examples, including apps that provided complex medical advice without any expert backup, or apps without security updates for several years. They’ve been though 5,000 apps, but there are 370,000 health-themed apps out there.

As a CIO, look in your systems list for information about applicable regulation. For every system, you should see a list of what regulations (GDPR, CCPA, HIPAA etc.) apply to that system, and the name of the person who has certified that this list is complete. For every regulation, you should also see the name of the person who certify that the system complies. If you don’t have that information in your systems list, you are probably releasing sub-standard systems.