Open fzaninotto opened 1 year ago
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.
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 ;).
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.
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.
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:
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.
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.
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