Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add GreenFrame to CO2.js #145

Open
fzaninotto opened this issue May 19, 2023 · 5 comments
Open

Add GreenFrame to CO2.js #145

fzaninotto opened this issue May 19, 2023 · 5 comments
Labels
enhancement New feature or request roadmap

Comments

@fzaninotto
Copy link

Model name
The GreenFrame Model, as used by https://greenframe.io

Documentation
https://github.com/marmelab/greenframe-cli/blob/main/src/model/README.md

Research
See above link for the references.

The model was originally developed by French CNRS, and named Argos. See https://marmelab.com/en/blog#greenframe for all the publications we (Marmelab, the creator of GreenFrame) dit on it.

Suitability
Websites, but can be used for other kind of applications if you use another RPA tool than PlayWright.

Usage
This is a developer tool.

Designed to be integrated into a CI workflow, to help validate/invalidate a carbon optimization in the code, and monitor and alert when a "carbon leak" is detected.

image

The GreenFrame model accounts for scopes 1,2 and 3 of all devices necessary for a given user scenario (client, network, datacenter), but doesn't estimate the emissions linked to manufacturing and disposal (only usage).

GreenFrame relies on metrics collected at the system level, not at the browser level.

See #138

@mgifford
Copy link

I didn't see in the GreenFrame approach if different types of content were evaluated differently. In our testing, JS & JSON files have a much heavier impact on energy consumption that either images or videos.

I'm also curious about how the license will play as https://github.com/marmelab/greenframe-cli/blob/main/LICENSE.md isn't compatable with Apache License or other popular open licenses.

@fzaninotto
Copy link
Author

I didn't see in the GreenFrame approach if different types of content were evaluated differently.

Again, GreenFrame relies on metrics collected at the system level, not at the browser level. GreenFrame doesn't mind if you're loading JS or JSON. It monitors the CPU (and memory, and network I/O, and the execution time) of the browser container and computes the energy consumption from there.

As for the license, it's up to you to keep only pure open-source projects, or open-source projects who try to protect themselves from large corporations ;).

@mgifford
Copy link

But in terms of giving guidance to web developers, GreenFrame is still just looking at data per page load and creating an aggregate number based on measurements and estimates of energy consumption. 

I think you'd be better off going with the GPL3 or AGPL if your goal is to protect it against large organizations. In extensive conversations with open source licensing experts, I'm very sure that the "it's up to you" approach doesn't work. If CO2.js adopts the GreenFrame approach, you gotta believe at some point it's going to get bundled into Google Lighthouse or other tools like that. It may not target your specific business model, but large corporations are very much involved in open source.

@fzaninotto
Copy link
Author

But in terms of giving guidance to web developers, GreenFrame is still just looking at data per page load and creating an aggregate number based on measurements and estimates of energy consumption.

That's correct - we don't rely on browser metrics like DOM nodes or timings because they are not accurate or not correlated with the energy consumption. We don't do static code analysis because code patterns aren't correlated with energy consumption either.

As for the guidance we provide, the idea is to trigger a GreenFrame analysis at each push to a repository. That way, when you detect a carbon leak, you know it comes from the previous push. We also highlight the infrastructure component (client, web server, reverse proxy, db) consumes the most, and at which moment of the user scenario the consumption peaks.

That's not enough to automate the fix of carbon leaks, because the eye of an acute developer is still requested to determine the culprit. But that's better than other tools, which provide advice based on non-proven heuristics, which often lead to no change at all.

If the objective is to optimize an existing app, the process is to pick a "good practice" in a GreenIT guide (e.g. https://gr491.isit-europe.org/en/), implement it, and test with GreenFrame if it has an impact. Let's call it the "Monte Carlo carbon optimization" ;) It's slow, but I don't know any other method. Of course, a code audit by a GreenIT expert often helps to prioritize these practices, but it's not (yet) a science.

I think you'd be better off going with the GPL3 or AGPL if your goal is to protect it against large organizations

Let's disagree on this one. Viral licenses are a red signal for most companies I know. The Elastic License, which is basically an MIT that just forbids to build a competing product to greenframe.io, isn't.

@mrchrisadams
Copy link
Member

Wow, thanks for opening this issue Francois!

So far, CO2.js has acted as a sort of container for existing models, to lower the barrier for implementing features of applications for folks who want to understand and reduce the environmental impact of digital services.

It would be really cool to implement the greenframe model, and the fact that there is so much research gone into is great - it seems to be a middle ground between the two main use cases we see right now:

  1. Using SWD or 1byte models in web focussed analytics/WPO tools - ( we do this with a number of 'downstream' projects or services - things like statsy, ecograder, web page test etc.))
  2. Offering easy access to emission factors for applications to self report energy figures (i.e. we do this with Firefox to support per-thread figures inside the browser, in profiler mode)

To be honest, we didn't really have any plans in the short term for implementing something as big as the greenframe model in the short term, because it seemed such a big job, beyond the resources are allocating to the project right now, and because I assumed it required the existence of a full end-to-end system under test, like the Green Metrics Tool from Green Coding Berlin. to generate the metrics.

However, after a second look, it looks like docker is mainly working to provide the input numbers like CPU usage, disk usage and so on for the model to. That might make is possible to restrict the scope, so that the greenframe model could plausibly exist in CO2.js, but where greenframe.io is the project implementing the model.

We've used an OSI approved license like Apache 2 for CO2 js - this is because we have been optimising for reach and ease of implementation, and everywhere else, where we publish code, we have used Apache 2, except where there is a norm around a license like the GPL with the wordpress community with our wordpress projects.

I'm not familiar enough with the Elastic License to have a well formed opinion about it yet, but I understand that it was initially set up to provide safeguards from very large cloud providers who might set up hosted services that compete with the original project.

Is the Greenframe model itself licensed under the Elastic license, or is it the just the greenframe-cli project?

I ask as while the Sustainable Web Design model was designed to be open to review and is implemented in a number of services and applications, not every implementation is using the version published under the Apache 2 license in CO2.js.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request roadmap
Projects
None yet
Development

No branches or pull requests

4 participants