Open Source Tools and GRI Reporting

[chrisn]

Section 5.28 Use Open Source Tools lists as High (i.e., "Significant long-term benefit") in relation to GRI 301 (materials), GRI 302 (energy use), GRI 303 (water and effluents), GRI 305 (emissions). Thinking of the kinds of tools that people use to build and deploy websites, it's really not clear that open source has any particular impact regarding those GRI specs as compared to non open source tools. Is there data or research to support these claims?

[AlexDawsonUK]

Good question, I'm not the one who did the recording, that would be @lmastalerz so he might be better equipped to answer - if he doesn't here I'll drop him a message to try to find out as he's our metrics lead.

My personal view (and maybe this is why they were listed as high) is that open source has tangible benefits in areas that may be verging on scope issues? (because the benefits are in areas such as improved security, potential for reduced technical debt with increased contributors, less likely to become abandonware if it can be forked and continued rather than disappear) - things which aren't strictly emissions related but fall under the remit of sustainability under good governance (being resiliant) and social factors of ESG (ethics, etc). If this is the case, we will be sure to re-examine the guideline (along with any others before inclusion in the final specification) to have a solution in place.

[chrisn]

My comment here was really about the GRI relationship, so focusing on the environmental aspects, which really would need data to substantiate including in this spec, "likely to be" really isn't strong enough IMO. Regarding the other benefits, there are numerous counterexamples where open source projects aren't sustainable (the frequent stories we hear of single maintainer projects, lack of funding, etc)

[AlexDawsonUK]

I've spoken with several people about this issue and I agree that as GRI is based purely on an emissions principle that the High rating doesn't match appropriately. I will regrade it to Medium because as much of open source is created on the server-side, there will be emissions generated from the software production but it won't be significant enough to deem it High (but it also may not be insignificant enough to warrant a low impact due to the potential for AI and end-user utilization for popular tooling). The change is now visible within the draft and will be published in the next version of the spec.

[chrisn]

I don't really follow. This guideline says:

The organization has clear policies about using open source tools, including how it gives back to the community and responsibly manages code repositories to reduce waste.

How does whether an organization has such a policy have any GRI related impact at all?

The examples you give are about actual use of software, which is separate to having a policy.

[AlexDawsonUK]

Policies within organisations can dictate practices regarding the choice of software. If their policy exists, it could specify restrictions against the use of high impact tooling or prioritise tooling that meets criteria regarding emissions (where data exists to push for its use over other products).

[chrisn]

So what I'm suggesting is that the spec here should focus on the selection and usage of tools. The creation of a policy in and of itself won't have environmental impacts, but I think I'm just repeating what I said before.

In addition, from an environmental perspective the spec could be clearer about what "manages code repositories to reduce waste" actually means (maybe something about reducing data storage needs?). Giving back to the community seems neutral for environmental sustainability, but important from a support and maintenance sustainability perspective (but whether these should be included is a scoping question).

I think the wider point I'm trying to make here is to be clearer about which kinds of sustainability each guideline affects, and that it's OK that somethings have no particular impact for one kind over another.

[AlexDawsonUK]

I get what you mean that a policy doesn't itself create environmental impacts but the consequences of having a policy could lead to impacts as a secondary consequence. This ties back to what we were talking about previously so naturally we don't need to repeat what's been stated.

What I will say is I agree that in principle this guideline should be re-examined (as they all should) when we get to the stage of inclusion in the final specification to ensure that ALL guidelines can be attributed to direct emissions within the scope of the charter and as with this guideline if a scope issue such as this occurs, we will ensure that the guideline is re-written to provide evidence-based advisory guidence that meets the requirements for inclusion within the spec otherwise it will be rejected from the WG. If that seems fair enough we could close this issue (as a CG matter) and re-examine it at the appropriate time when each guideline will be determined for readiness for the final version of the specification?

[AlexDawsonUK]

As this has been open for a week with no additional feedback, and further discussion will take place at a later date (regarding scope and individual guidelines before being submitted to the final specification), I'll close this issue as charter related matters are taking place elsewhere and any resolved content will be published in the upcoming draft.