Key Takeaways:
- The race to decarbonise supply chains is already being enabled by software, but we have barely scratched the surface of the efficiency gains possible with Open Source.
- Organisations should instead shift their focus to creating, contributing to or using an open-core for innovation to occur, which will enable the market to aggressively lower green premiums.
- It is my opinion that the correct place to engage in market competition is post the creation of accurate emissions figures, where ideally, we get a race to the bottom for carbon emissions intensity.
- I wholeheartedly believe that given the state of the climate crisis, double-spending valuable resources on the development of common software functionality is an activity that should be given the CO2 treatment, it should be Net Zero.
- The solution isn't in knowing where the emissions are in your organisation, product or supply chain, it’s in the abatement activities undertaken to reduce the emissions and drive a less carbon intense society.
- We require a simplified way of working with carbon accounting methodologies in our software, replacing the duplication of software development processes, with the technology output of pooled resources defining technical specifications from common sustainability reporting and methodological standards.
- Defining technical standards that allow for commodity solutions to be developed that directly align with carbon accounting methodologies and reporting standards is an example of stellar forward thinking that will allow a push towards net zero and decarbonisation.
- Developing standards and solutions openly, with high levels of reliability, quality and a constantly developing expertise, there is a potential to create a launchpad for rapid velocity and growth of the applicability of carbon accounting.
Software is near and dear to my heart, and I have discussed how I got into programming in other posts, as I have also covered the last two years of my headspace being progressively overrun by Carbon Accounting. I have an idealistic belief that we owe ourselves and the planet a fair attempt to solve anthropogenic climate change. I also believe that an Open Source approach to building software for Carbon Accounting and ClimateTech is not only the optimal way of building excellent software, but an emissions reductive methodology from a product life cycle perspective.
The race to decarbonise supply chains is already being enabled by software, but we have barely scratched the surface of the efficiency gains possible with Open Source.
Fundamentally, I develop open source solutions under the ZeroTwentyFifty banner because of a deep seated personal belief that climate change is such a vast problem, that obsessing over creating walled gardens around commodity-software, is perhaps not taking into consideration enough of our need for scalable decarbonisation solutions.
Organisations should instead shift their focus to creating, contributing to or using an open-core for innovation to occur, which will enable the market to aggressively lower green premiums. This is a far more effective weapon in the decarbonisation armoury. It is the wrong place to fight over methodology and calculation solutions. It is my opinion that the correct place to engage in market competition is post the creation of accurate emissions figures, where ideally, we get a race to the bottom for carbon emissions intensity.
I wholeheartedly believe that given the state of the climate crisis, double-spending valuable resources on the development of common software functionality is an activity that should be given the CO2 treatment, it should be Net Zero.
The scale of the decarbonisation solution
Neither the scale or need for rapid decarbonisation can be understated, this is the reason for the Vaclav Smil quote on our landing page; it’s also why it bares repeating here:
By the time the Manhattan Project ended in 1946, it had cost the country nearly US $2 billion, about $33 billion in today’s money, the total equal to only about 0.3 percent of the 1943–45 gross domestic product. When Project Apollo ended in 1972, it had cost about $26 billion, or $207 billion in today’s money; over 12 years it worked out annually to about 0.2 percent of the country’s 1961–72 GDP.
Of course, nobody can provide a reliable account of the eventual cost of global energy transition because we do not know the ultimate composition of the new primary energy supply. Nor do we know what shares will come from converting natural renewable flows, whether we will use them to produce hydrogen or synthetic fuels, and the extent to which we will rely on nuclear fission (and, as some hope, on fusion) or on other, still unknown options.
But a recent attempt to estimate such costs confirms the magnitude of the category mistake. The McKinsey Global Institute, in a highly conservative estimate, puts the cost at $275 trillion between 2021 and 2050.
That is roughly $9.2 trillion a year, compared with the 2021 global economic product of $94 trillion. Such numbers imply an annual expenditure of about 10 percent of today’s world economic product.
In 2023, humans collectively produced roughly 40.9 billion tonnes of CO2 emissions, representing a 1.1% increase over 2022 numbers. In order to constrain the worst impacts of climate change and hold us to a 1.5 degree impact, we need to reduce by 1.5 GtCO2 per year. For reference, this is less per year, than the observed impact of the COVID-19 pandemic on world emissions levels, which collectively netted the planet a 2.0 GtCO2 reduction.
In order to inform decision making around emissions reduction we use Life Cycle Assessment (LCA) and Product Carbon Footprinting (PCF). As a global community, we can measure and analyse the facts and figures of our product processes and how we use products and services at a life cycle level in minute detail, but the rubber ultimately hits the road when we start trying to actually reduce and remove those emissions.
The need for a stable base
When solving complex problems; we rely on a foundational base of pre-existing knowledge, practices and technologies.
In order for us to progress the state of the art and achieve further innovation, we ultimately need to take the knowledge, experiences and practices that we have and crystallise this into a stable and coherent base upon which to work, a clean canvas, if you will, on which to paint.
This can be perfectly exemplified by the rise of the internet:
- We have the early internet, which was run by universities and research organisations, and came about as a result of a scientific need to provide access to digital information.
- The internet was then commercialised, being made widely available to the public via consumer facing organisations through their own large scale and self-hosted servers, either on their premises or on hosted premises.
- Then came cloud computing, which has enabled the extremely rapid development of web services and applications, because it removes the need for organisations to procure hardware, they just write code and deliver.
When you combine this need for earlier iterations of a state of the art, with the urgent reality of the need for decarbonisation, what is left is a need for a rapidly available and stable base of technology on which everyone can build. It makes no sense for everyone to build their own versions of the most basic elements of the problem space, when that time could be spent much better on solving real issues of decarbonisation. This is also well reflected in the research on the use of Open Source technology.
The solution isn't in knowing where the emissions are in your organisation, product or supply chain, it’s in the abatement activities undertaken to reduce the emissions and drive a less carbon intense society.
This problem space does not lack complexity. With a range of reporting standards; some mandatory, some voluntary, methodologies, legislation, technologies, approaches, organisations and then the overall general complexity of conceptualising, valuing and measuring a previously ignored, publicly offset liability of economic activity, there is no need to further complicate a rapidly progressing space that needs to go faster.
The philosophy behind using open source software to create this base
There are difficulties involved with aligning the results of our carbon accounting practices, methodologies and reporting.
We require a simplified way of working with carbon accounting methodologies in our software, replacing the duplication of software development processes, with the technology output of pooled resources defining technical specifications from common sustainability reporting and methodological standards. The resulting outcome would be software that can be extended for our individual purposes, that utilises the collective benefits of the core requirements that everyone has had to build themselves.
Ultimately, I’m skirting around the fact that I am calling out some amount of proprietary software development as wasteful, with common functionality developed in isolation, it means that we are collectively repeating the same behaviours hundreds of times in various places.
Let's assume there are 3 independent producers of a software product, none of them ever talk or communicate, but they are all working to utilise the same carbon accounting methodology. This process could contain a number of activities required to implement useful software that poses a benefit to their users:
- Reading through the carbon accounting methodology documents themselves
- Generating more structured requirements from the documents
- Turning those formal requirements into technical requirements for use by software developers
- Producing designs for the software
- Actually turning the designs into working code
- Any additional processes designed to ensure that what’s been specified is in line with the original methodology documents.
As you can see, with our fictional example of 3 companies all hoping to simply be able to support the use of our carbon accounting methodology, all parties must develop the same set of base features before implementing any features that might more directly implement the “vision” they have of their unique product market fit and product.
These “custom features”; as I have named them in the above diagram, are most likely to be revenue generating and representative of the unique selling points of each company. They are, in reality, the reason businesses exist, not a single one of these organisations particularly care about implementing the same features everyone else has; which we have labelled “same feature x”, there’s no real benefit to it.
However, with a new approach of utilising or contributing to a common core, we allow for organisations to quickly ramp up, whilst standardising the most inane components of the carbon accounting methodologies, and immediately move towards delivering legitimate value.
Moving away from a fictional example, this would look like the requirements set out by the PACT Network technical specification.
Everyone must implement the requirements in order to become PACT Conformant, which requires dedicating their own companies time to the problem, in order to produce what we can actually state to be a mirror image solution to the other 2 solutions produced by the companies.
As an aside, this is an excellent place to be, the standardisation process occurring via the PACT ecosystem is an excellent example of cross-industry cooperation resulting in more consistent data exchange standards for the exchange of Product Carbon Footprint data, this stands in stark contrast to how it has worked in the past, which I’ve talked about a bit more here.
This can mentally be extended quite easily to other areas of Carbon Accounting, in the situation of the GHG Protocol and the various standards set out, these are all the same if they are implemented to the letter across various organisations.
As another example, if we were to ask 3 organisations to take the GHG Protocol Corporate Standard and write a software system from it using only that document, ideally, they would all produce the same thing if they all paid enough attention to the document.
However, with a new approach of utilising or contributing to a common core, we can see that everyone gets to now use the same features that they’d all produced in isolation prior, with the new ability to simply put their own spin on it.
Let’s think more seriously about this, in the case of the GHG Protocol suite, listed here:
- Corporate Standard
- Scope 3 Standard
- Product Life Cycle Standard
- PACT Methodology/Network
It's only the most recently released of the suite; the PACT Methodology, that has chosen to directly tie a technology based artefact to its standard-setting process and the associated output. This has generated enormous benefits for all those seeking to use it. For participants of the PACT Network, they can come to rely on a stable and known data format for communicating the Product Carbon Footprint that exist for their own product lines, allowing them to request PCFs from their suppliers to utilise primary data in their own carbon accounting methodologies, which has innumerable benefits when compared to the use of secondary data. We have an introductory post on the PACT Network here.
An ideal solution to a complicated problem
Accounting as a whole is the ideal problem space for software, it is a rules based system that seeks to define conditional logic, which is exactly what software is at its purest form. Defining technical standards that allow for commodity solutions to be developed that directly align with carbon accounting methodologies and reporting standards is an example of stellar forward thinking that will allow a push towards net zero and decarbonisation.
In the case of the PACT Methodology, there are currently three cross sectoral standards defined for the representing the calculation of results:
- GHG Protocol Product Standard
- ISO Standard 14067
- ISO Standard 14044
And in coming versions, the set of methodologies is being expanded to support:
- ISO 14067
- PACT Methodology v1
- PACT Methodology v2
- GHG Protocol Product Standard
- PAS 2050
- ISO 14040-44
- PEF
- Other
As the list of methodologies through which organisations can calculate their carbon emissions expands; the usefulness of carbon accounting increases, but at the same time, we run the risk of increasing complexity across the ecosystem. In our previous example and diagrams, we visualised a make believe scenario where the amount of duplicated work to be performed increased linearly by the number of organisations in the solution market. However, that example was representative of only a single carbon accounting methodology. We just outlined how the PACT Methodology and Network seeks to increase the available methodologies from 3 to 7. This increases the amount of work exponentially.
Whilst it would be a ridiculous assertion to suggest that all organisations need access to all methodologies all the time, it is not ridiculous to suggest that there are now enough methodologies in existence to warrant a pooled effort to software development in order to ease not only the initial development but also the maintenance burden of the undertaking.
I cover off more of the benefits of such an approach in another article of ours, Why are you developing ZeroTwentyFifty Open Source?
Developing Trust
I’m not ashamed to say that I can get a bit poetic when talking to people about my vision for much of this space. I believe that while Climate Change poses an existential threat, Decarbonisation is the opportunity of an age, one that will never be overshadowed by something larger. The potential for transformational economic and societal value creation mirrors the scale seen only by our discovery and subsequent application of fossil fuels. It dwarfs the internet and the AI boom, and common historical references for the might of human ingenuity, such as the Manhattan Project and the Apollo Mission are multiple orders of magnitude smaller than the problem that lies in front of us.
I am looking forward to having conversations with the following future thinking groups:
- Software practitioners looking to build the future of carbon accounting in an open manner, to enable velocity, reliability and the rigour of carbon accounting practices.
- Organisations looking to use, contribute or test software libraries, systems and programs within their software or organisations, in order to spend less time worrying about calculation and more time focused on abatement or to build software systems in partnership with ZeroTwentyFifty.
- Sustainability professionals that can provide expertise and guidance on best practices and ways to actually produce the best software possible that is usable and useful to those who wish to use it.
I believe that by developing standards and solutions openly, with high levels of reliability, quality and a constantly developing expertise, there is a potential to create a launchpad for rapid velocity and growth of the applicability of carbon accounting, developing this alongside the growth of the Internet of Emissions Data will provide the technological innovation to have impact on what matters most; getting to Net Zero.
