question about boundaries, infrastructure components, and the development of the software

[martinlippert]

I have a question regarding the boundaries section that isn't totally clear to me.

From what I understood, the boundary of the software "MUST include all supporting infrastructure" (and a list of examples follows over there). It sounds to me like systems that are used while developing the software (e.g. "testing", "build and deployment pipelines", "scanning") are also taken into account here. Is that the case?

If that is the case, they would contribute to the how much carbon ("C") is caused by the software, which would then also scale with "R". I think that can lead to some confusion. For example: I have an infrastructure component that is used to test my software, but the amount of carbon that this testing infrastructure produces is somewhat independent of the number of functional units that I run ("R").

So maybe the section about boundaries and the functional unit should mention that the boundary should include all components that "scale with" the functional unit - or should be treated as an independent software otherwise.

Maybe this is also related to the section about the embodied emissions: would it be possible (or make sense) to include the emissions that were caused while producing the software itself? At the moment this is purely related to hardware components, but it feels to me like the software itself comes with embodied emissions from its development - and it could be interesting to take that into account here.

What do you think?

[Henry-WattTime]

Working group:
Other lower environments as well (dev, test, etc). Is each developer environment included?
Partially included:
"Supporting systems may include [...] building and deploy pipeline, operations, monitoring, backup[...]" - Maybe needs Devops costs/emissions
example:
developers searching for ideal architecture will have significant impact.

Maybe for v1: advise to split into running cost and development cost,
-maintaining and deploying updates has significant costs/impacts

But do not scale by same R/functional unit, how do we overcome this?

LCA precedent: Split into stages [raw material, production, use, end of life]. Shows breakdown. Use model for SCI spec.

Distinguish between the two spheres (operating and development), maybe report separately. Bridge that distinction, maybe version 2 accommodates this.

looking at production system and how they operate, always trying to minimize production scores. Some additional consumption in development.
Embedded system - no access to later, one off choice.

Holding future version. Dig into the issue with case studies. Identify if a change needs to be made. Converting to discussions, will migrate to issue/PR.

[srini1978]

I was thinking about this and adding a constraint in the "boundaries" section that the SCI value is calculated for infrastructure that align with the "functional unit" R is a good statement to add.

This basically means that the "SCI components" of E and M are included only for those infrastructure that scale with the functional unit of R. And this aligns with the discussion we had in working group around the concept of v1 and v2. @Henry-WattTime @atg-abhishek

A statement to this effect is here where we say the functional unit is the unit by which infrastructure scales -

https://github.com/Green-Software-Foundation/software_carbon_intensity/blob/e38cd06b27fb6b712e28a03c50c9c81db66ff8fd/Software_Carbon_Intensity/Software_Carbon_Intensity_Specification.md#functional-unit-r

But I have made it more explicit with this pull request. Created pull request #226

[atg-abhishek]

Thanks for making that PR @srini1978 - let's review it during this week's WG call :)