Characteristic: Simple or Complex

[jawache]

The more complexity in calculating the software carbon intensity, the fewer people and teams that will adopt it.

How do we make things simple so they are easy to adopt, and yet not so simple that they lose accurate information?

One direction could be in using tooling or modelling as much as possible in calculating the number (in the specification we need to steer clear of implementation details but we can describe the types of tooling that might help).

Another direction is to leverage as much as possible existing methods of calculation but adjust them to fit our desired characteristics. E.g. cost, energy, network bandwidth and have our own emission factors which people can use to multiply out to a carbon number.

Perhaps being consequential makes our life a lot easier, if we ignore calculating the total carbon emissions and just focus on what are the emissions when just one more person uses your application, does that make things simpler?

[Hevia]

I think the biggest barrier in adoption of tooling is friction. How can carbon calculators be as frictionless to adopt into an existing codebase as possible? If it adds additional complexity, I can imagine folks will not want to deal with it unless they deeply care about the cause.

Perhaps being consequential makes our life a lot easier, if we ignore calculating the total carbon emissions and just focus on what are the emissions when just one more person uses your application, does that make things simpler?

I really like this idea!

I think Website Carbon accomplishes both points well. Its frictionless to use, and it provides the emissions per visitor to your site.

CodeCarbon is a good example of frictionless emission recording for total app lifecycle. Its as easy as importing the tracker and then starting/stopping the bit of code you want to track.

[rfsalomon]

Perhaps being consequential makes our life a lot easier, if we ignore calculating the total carbon emissions and just focus on what are the emissions when just one more person uses your application, does that make things simpler?

It seems that there are separate domains, and they should be treated separately. On one side, a software execution standard (modelled after SpecInt?) that could show how carbon efficient a hardware/software combination is. This would provide a reliable index that would incentivize software developers to write the most efficient software possible for a hardware market that already exists while driving the hardware industry to develop more carbon efficient solutions for software to run in.

The second domain could be seen as cloud software usage where the distribution of the processing result would be measured. This seems to be more in line with what the Website Carbon tool accomplishes. Since this efficiency valuation would have to address components over which the developer has little or no control (such as routers, telecom operators, and others), I really don't see a straightforward way to address this.

I agree with @jawache in that being consequential is necessary and I also think that separating the domains would make life even easier in recognizing the different scopes of carbon emission in the industry allowing us to produce indexes that could be usable from the on-premises programmer to the cloud application developer.

[atg-abhishek]

CodeCarbon is a good example of frictionless emission recording for total app lifecycle. Its as easy as importing the tracker and then starting/stopping the bit of code you want to track.

Low friction is going to be a key tenet for boosting adoption amongst developers @Hevia ! I talked about the Code Carbon tool and the state of tooling as it stands today a bit more here: The current state of affairs and a roadmap for effective carbon-accounting tooling in AI

[atg-abhishek]

The second domain could be seen as cloud software usage where the distribution of the processing result would be measured. This seems to be more in line with what the Website Carbon tool accomplishes. Since this efficiency valuation would have to address components over which the developer has little or no control (such as routers, telecom operators, and others), I really don't see a straightforward way to address this.

I like this distinction that you draw @rfsalomon - maybe we can acknowledge this explicitly in the document so that at least people can see that we considered it (and are open to solutions!).

[jawache]

I like the idea of low friction to entry, with increased accuracy the more effort you are willing to put in.

Anyone, without much experience or training, should be able to follow the instructions in the SCI spec to measure the carbon intensity of their piece of software.

We can build tools (in the Innovation WG) that automate this process, but the SCI spec shouldn't refer to them or depend on them, we can fall into some complex patent traps if we start talking about implementation. Put it another way, the safest place to be from a patent perspective is for the spec to describe how to solve the problem in such a way that there can be multiple implementations and multiple tools to automate the process.

[atg-abhishek]

Indeed @jawache we don't want to be too tied down to a specific implementation. Would there be a badge of some sort that could be offered (similar to something brought up in previous discussions) where we can say that tool X adheres to the SCI and that would help people wanting to utilize this know which tools to pick? This could also be manifested as a "suggested" list somewhere on the GSF resources or would that violate the expectations from a GSF perspective?

[atg-abhishek]

Sarah: It would be good to find out what the roadblocks are - finding the right things to measure and how to measure them. Finding common ground for all different scenarios. For own cloud providers and data centres, getting the data is hard.

Siu: It would appear that the innovation WG's work and our work will need to be aligned.

@seanmcilroy29 to create a new issue to talk about the badge thing for "conformance" to the SCI Would there be different badges for different levels of conformance with the SCI?

[Henry-WattTime]

This simplicity topic might also tie to the #22 issue discussion around granularity and timestep. Higher granularity/higher complexity might also get a "higher" badge or compliance rating.

[atg-abhishek]

Good point @Henry-WattTime , this also probably ties to #27 in terms of the spatial granularity with again higher detail getting a "higher" badge #24

[jawache]

Do you feel this issue is in a good enough state for me to create a PR for this characteristic @Henry-WattTime @atg-abhishek ?

Something along the lines of:

• Low friction to entry
• Reduced accuracy is ok (to begin with) as long as directionality is accurate.

I can review the comments above and incorporate them.

[atg-abhishek]

Yes I think so @jawache 🔥

[atg-abhishek]

Have you had a chance to work on this @jawache ?