Abhishek Gupta of Microsoft and Henry Richardson of WattTime are Co-Chairs of the Software Carbon Intensity (SCI) Specification Project of the Standards Working Group. The alpha version of the SCI was launched in December 2021. You can read more about the process of how the SCI specification was crafted in an earlier article from Abhishek. In this interview the Co-Chairs talk about what the future holds for the SCI Specification.
First, tell us why each of you find this project exciting.
Abhishek: I’m first and foremost a practitioner. The Software Carbon Intensity (SCI) specification is exciting because it is a concrete manifestation of broad—and very important!—ideas of how we measure the carbon impacts of software systems. But, more importantly, is it about what we can do to mitigate those impacts. The SCI comes with an action-oriented approach, putting the needs of hands-on practitioners first. This way, the guidance that emerges from its use is actionable and meaningful.
Henry: I am very enthusiastic about the SCI because it opens up new avenues to provide a new group of people—software developers—with the tools they need to achieve energy choice and actively reduce emissions. I am excited to bring a grid-oriented viewpoint to the specification to complement the software focus many other participants bring to the table.
Tell us more about the SCI project.
The Software Carbon Intensity (SCI) standard gives an actionable approach to software designers, developers and deployers to measure the carbon impacts of their systems. The SCI uses a lifecycle and consequentialist approach with the goal of empowering the consumers of software systems to make informed choices about the carbon impacts of those software systems.
The roadmap for v1 of the SCI is to have a stable of use cases that show the SCI in action. These use cases provide templates for others to easily adopt the SCI for their own projects. As we flesh out further the reporting standards associated with the SCI, our ambition is to make the SCI into a veritable standard that is adopted and used daily by software practitioners around the world.
Why is this project important?
The SCI is central to all the activities at the Green Software Foundation (GSF). It is the cornerstone upon which the GSF is seeking to make an impact in helping individuals and organisations make contributions towards achieving their sustainability goals. Given that it is action-oriented, it is a testament to all the other activities at the GSF as well, which are centred on empowering individuals and organisations to not just “talk the talk” but actually “walk it.”
What progress have you made so far?
We have made progress through the support of practitioners from industry leaders who have participated in shaping the alpha version of the SCI which is already available for public consumption.
The alpha version of the SCI, released for public comment in December 2021, operationalizes this through the following:
The SCI is sensitive to carbon awareness, energy efficiency, or hardware efficiency
The SCI takes a systems-footprint view
The SCI is easy to implement
The SCI encourages the use of granular data
The SCI requires the use of a standardised and transparent reporting mechanism of what goes into the calculations.
What are the main areas of the project?
The main areas of the project are development of the SCI itself which involves weekly deliberations with members of the Standards Working Group towards each of the items that we have on the roadmap. The reporting standards and use cases are the supplemental areas of work related to the SCI which are being led by various individuals within the Standards Working Group.
How does the SCI Specification project operate?
We work via consensus and voting. Our aim is to ensure all members agree on all changes to the specification, in the case where we cannot reach consensus we hold a vote.
We work entirely through GitHub. Here’s our GitHub repo. We first discuss ideas in the discussions tab. Once we are happy with the state of the discussion and are ready to make a change to the specification, we move the discussion to a GitHub issue and start working on details of the pull request (PR). Eventually one of the team members creates a PR and we then have a process by which we agree on the merging of the PR.
How can someone get involved? Is it only GSF members who can get involved? Is there a way for non members?
Since all of our work, meeting notes, and agenda items are publicly visible on the GitHub repo, we encourage anyone who is interested in the domain to bring their ideas to those discussions. The live Standards Working Group meetings are reserved for GSF members though there is the potential to invite guest speakers and external contributors on occasion. We also now have a Discourse forum where we invite the broader green software engineering community to come and engage with us on the subject.
What does an individual GSF member get from becoming involved in your project?
GSF members participating in this project have the opportunity to engage with peers who are experts in the domain of green software engineering. And they have the potential to contribute to a standard that will shape software engineering practises across the industry for decades to come. It is a way for anyone to distinguish their own software practices and help to make a real impact in the world rather than just talking about it.
GSF members who are interested in joining the project should email the Co-Chairs or contact them via GSF Slack.
Case studies and use cases are central to the roadmap for v1 of the SCI. We actively invite contributions from practitioners who are exploring how to apply the SCI to their projects with a view to meet their sustainability commitments. There is a handy template available on the SCI GitHub repo that one can use to make this contribution.
What challenges do you see for the project and how do you plan to overcome them?
The biggest barrier at the moment is a dearth of case studies.
Another is the broader inertia in the domain around existing ways of carbon accounting like the Greenhouse Gas (GHG) Protocol which is attributional vs. the consequentialist approach that is advocated within the SCI. Through our publications and engaging with the software community, we’ve seen momentum in using our approach and how it is better suited to carbon impacts assessment for software compared to existing methods.
What can we expect from your project in the near future?
We anticipate that we will release a new version of the specification this fall, after we’ve had a chance to test the current version against the case studies we are currently developing. This will help us identify any improvements and refinements that need to be made to the SCI to better serve developers and achieve real-world emissions reductions. We think the case studies will be a key tool for both refining the SCI as well as helping achieve widespread adoption.
This article is licenced under Creative Commons (CC BY 4.0)
