I’v spent most of my career building custom software for large businesses. Living in Houston means most of these large businesses are Fortune 100 energy companies which means most of the custom software I have been involved in delivering revolves around the production, movement or marketing of energy including natural gas, crude oil, refined products as well as power. What most of these companies know, but which have yet to actually do something about, is that most of the baseline software they pay millions of dollars for doesn’t actually give them a strategic advantage – it’s table stakes.
The deregulated power industry is a great example of this duplication of non-value add software. The retail power business is a commodity business with very few differentiators between providers. They like to say they are different but for the most part, they are not. It’s electricity. There’s no secret sauce to it. And even unlike retail gasoline, which tout all kinds of additives and such, electricity is just electrons. The services are all the same. They all have auto-pay. They pretty much all support average pricing. They all charge you the same late fees. The only difference is how much you pay for it. It’s pretty much all marketing and price.
When price is the main differentiator, then the name of the game is always cost reduction. It’s about being able to deliver the same undifferentiated product or service cheaper than the competitors. Sure, there are subtle nuances to customer service such as flexibility and honesty, but those should be considered requirements to a viable business, not a real differentiation. Ask most energy consumers if they would buy the same product from someone who is a jerk if it saves them 10% and you’ll get the truth about competition in a commodity market. If you are a company who competes in a space where you are selling a largely indistinguishable commodity, then your top priority is cost reduction.
Going back to the retail power industry, in terms of cost reduction, one of the best way to cut costs is automation. The retailer wants someone to sign up online, do auto-pay with a credit card and use electronic forms. They want to be able to take the information they received from the customer and automatically submit the needed information to the utility to enroll them. They want to be able to automatically get the meter read cycle back from the utility and schedule that customer’s usage data to be pulled on a monthly basis, sending it into a billing system where the invoice is automatically sent out to the customer’s email and then on the date denoted by the customer autopay agreement, the on file credit card will be charged. They want to then take all of those payments and have then flow back into their accounting and finance systems. No humans. All software.
The description of the automated processing above isn’t rocket science but there are a wide degree in which retailers have automated these processes and even more so, there is a very wide degree in three key factors:
- How much they paid to build/buy the custom software to automate these processes
- How much they continue to pay to maintain these processes
- How much these costs are spread in terms of a per-kwh
Why Open Source
The main fear most companies have of open source model is rooted in the understanding of software licenses. Let’s say a retail company decides to open source the application used to automate the process of enrolling a customer. The main fear is that they will fully incur the costs of developing the software but allow their competitors to get the value of it with little or no costs. The reality is that the software development process of maintaining software can make this very difficult.
Bugfixes are a great example of this. Let’s say the enrollment software has a bug. To fix the bug, a developer will fork the code (v1.4.6), make the changes, add the tests to validate the fix and then submit these changes back to the main project. The changes, upon approval, will then be pulled back into the open source project which will then release a new patched version (v1.4.7) which will include this bugfix but also may include 5-6 other bugfixes submitted since the last release.
If I’m a “freeloader” company, who takes from the project and never gives back, then I am having to maintain the bugfixes and other new features in a completely forked set of code. Each time there is new release, if I want to continue to get the value of the new versions, then I will have to pull the new version and manually merge all the changes with the internal versions of the code.
The longer the time horizon is, the more drift between the open source version and the internal version occurs, thus making the additional costs as risks associated with manually patching to be hard to justify. In the long run, the open source model encourages cooperation because the amount of costs and risks associated with maintaining a proprietary branch become greater than the value of “stealing” the source.
Another misnomer of open source is that it eliminates costs associated with software. The reality is the company’s choosing to engage in a open source software model are reducing the costs associated with proprietary software development. The costs of implementation are still there. You will still need developers that understand the code and can fix things. They still fix bugs and create new features. The main difference is that they are spending their time building new value rather than rehashing the same code that’s present in 20 other companies just like yours. Reduced scope results in reduced cost.
Alignment with Microservice Architecture
The microservice architecture movement also lends itself to open source. If a companies application architecture is a monolith, identifying and releasing the code associated with generic capabilities is almost impossible. However, as companies begin to break those monoliths into microservices, then the boundaries between truly proprietary source code and generic non-proprietary domains become clear. For example, how a retail provider estimates and hedges their expected load is definitely a proprietary and differentiated part of the software but retrieving meter data from the utility is absolutely not. By creating two separate services – one to retrieve the data and then one to aggregate and build estimation models – the company can then open source the data retrieval piece and gain the benefits of community development. In this particular case, if the utility is on board with the open source implementation, they might even manage a majority of the updates as part of their services. It’s in the utilities best interest because it could dramatically reduce their support requirements as well.
Getting Started
It doesn’t have to be a huge effort. Pick the low hanging fruit. Find a set of concerns and start talking with your regional industry associations about how this might work. Release something and see if others start contributing as well. Someone has to start the ball rolling and the initiation can feel a little lonely but the value of open source might end up being the thing that helps you compete effectively.