Venture capitalist Marc Andreessen was correct when, in 2011, he said software would eat the world. Although he didn’t mean that literally, the material, climate impact of software is now too large to ignore. The energy used by modern technology is tremendous. The switch to digital working over the pandemic increased the burden. And with the march of generative AI, that burden will balloon even further.
With regulators and politicians under pressure to reduce carbon emissions, tech companies are under newfound scrutiny for energy-guzzling infrastructure such as an ever-expanding data-centre estate. But given that this infrastructure is mostly used to power software, perhaps it’s not just hardware that needs to be under the spotlight.
Since 1992, manufacturers in the US would send their equipment or devices away to a government laboratory to be measured for energy efficiency. If they met the criteria, those manufacturers could apply an Energy Star label onto their product to prove its green credentials. The EU has a similar scheme, with products rated on a scale from A to G.
The energy consumption of software is much trickier to calculate than it is for a kettle or a microwave. There is no lab to send software to. Businesses could self-certify their software, but then consumers would have no trusted, verifiable way of ensuring the data is accurate.
Perhaps, argues the Green Software Foundation, if we could more easily determine the carbon emissions each software component created, acceptable emissions standards could be set and the environmental impact of software could be reduced.
This is the thinking behind the Green Software Foundation’s Software Carbon Intensity (SCI) specification. Speaking at the Open Source Summit in Vienna last week, its executive director, Asim Hussain, set out the organisation’s vision for how developers and technologists can help tackle the climate crisis.
The SCI specification – what is it and how does it work?
The SCI is a specification for defining the carbon emissions generated by software. Its methodology helps users and developers make more environmentally friendly decisions about the tools and services they use.
“There hasn’t really been a KPI for sustainability [in software],” Hussain says. With approval from the International Organization for Standardization (ISO), CTOs can be confident in using the SCI specification to calculate the emissions of the software they use, he adds. “They know other organisations are using this mechanism so they’re not going against the grain – they’re choosing a standard.”
This information can help to reduce or avoid creating emissions through the use of software. The SCI has already been adopted by academics and technologists. Major technology companies, including Microsoft, NTT Data, Accenture and Intel, have all signed up to the Green Software Foundation, a non-profit under the Linux Foundation to create a trusted ecosystem for building environmentally friendly software.
If the SCI specification defines how to calculate carbon emissions, an accompanying tool, called Impact Framework, turns this data into insights.
The Impact Framework tool is a calculator that allows users to input observations, such as computer processor utilisation, visits to a website, or the number of installations of a piece of software, and receive an estimate for the amount of carbon generated by each action.
The tool is agnostic to environment and device so, as the specification evolves, it could eventually be used to measure more complex systems – for example, carbon emissions per GenAI prompt.
With custom plug-ins, users can calculate uncomfortably morbid but sobering stats about how many deaths the carbon emissions of their software will cause. Some developers are experimenting with using the Impact Framework to calculate the emissions of physical supply chains, for example the carbon emissions created when delivering a parcel from A to B, with multiple stops along the way.
But it’s still early days. The specification was certified by the ISO last year. Although some academics and developers are already using the specification, the Green Software Foundation hopes more companies adopt its framework.
Solving ‘the measurement problem’ in greening software
In the 18th century, French merchants and the peasantry were frequently defrauded by traders, who used their own opaque, competing measurement systems. The lack of a single system of measurements was listed in the Cahiers de doléances, the ‘ledger of complaints’ that king Louis XVI ordered compiled shortly before he lost his head: “Throughout the whole kingdom there should be but one code of laws, one system of weights and measures,” they demanded.
This demand eventually led revolutionary France to adopt the metric system, which used measurements drawn from immutable facts of nature – for example, the metre is a percentage of the circumference of the earth – to enforce equality in measurements and ensure fairer trading.
I’m a firm believer that if we solve the measurement problem, the rest will follow
Metrology obsessive Hussain has taken inspiration from historical precedents and believes stories like these speak to how, historically, measurement systems have been used to hold power over the masses – but also how they can be used to dilute and distribute power, such as in revolutionary France.
More recently than 1789, software developers had battled with how to measure sustainability.
“We didn’t know how to measure properly, and so people weren’t measuring,” Hussain says. “People kept talking about ways to reduce emissions, but couldn’t prove how many emissions it would reduce. It’s easy to tell people to use fewer servers but how much is that going to save? We didn’t know.”
“But engineers are brilliant,” he adds. “They’re building infrastructure that can figure out the most unbelievable solutions to problems. If we show them how to measure sustainability, they will figure it out… I’m a firm believer that if we solve the measurement problem, the rest will follow.”
Why open source and open data matters for the climate
Tools to measure the carbon emissions of software did already exist. A key difference of the SCI and the Impact Framework is that public data can be used. Unlike other systems, the Impact Framework is also customisable, Hussain says. This allows users to fine-tune their modelling to support their specific use case or tech stack.
By using open data, anyone can theoretically audit the carbon footprint of any piece of software, regardless of the company that made it. For example, during a recent hackathon in California, a group of teenagers calculated the carbon emissions of a Zoom video call.
“A bunch of 16-year-old kids demonstrated to a multi-billion dollar organisation how to measure its emissions,” says Hussain.
He adds that the SCI will enable organisations to be more transparent by allowing them to prove their sustainability credentials. By adopting a common framework, companies will also be able to more easily explain how they achieved their scores if, for example, they’re accused of greenwashing.
“I’ve been inside organisations that want to disclose their emissions but they’re fearful they’ll be criticised for calculating it in the wrong way,” Hussain says. A better model, he suggests, might be an ongoing, open, public dialogue, instead of the annual ESG reports that are currently the norm.
“If someone in the open-source ecosystem calculates an organisation’s sustainability score, don’t view it as a threat,” he says. “If they made a mistake, help them out and show them the way you’d calculate it.”
A few decades ago, open source itself was on the fringes until some of the largest corporations – and former opponents – reversed their position.
Like open source’s decades-long trajectory into the mainstream, Hussain says, transparency in sustainability is going to be a “challenging journey”. But, he adds: “I fully believe the future will be complete transparency of these numbers.”
