The velocity reports are great, but they bias towards older projects because they just look at absolute numbers. Would it be possible to add a time dimension to the velocity reports so we can see which projects are speeding up or slowing down?

Hi, how are you? I'd like to collaborate on your open source project and propose free logo/icon design for this project. If it's something you're interested in, please, let me know!
Best Regards
Zuur

The "Chart" sheet in for the "Top 30 projects" Google workbooks reads "Top 20" and needs to be fixed.

For example: https://docs.google.com/spreadsheets/d/124e8u53eq-zCPPnA3ICe0LIPkOmVlxakMmka_8t9w_A/edit#gid=134798507

I had requested "edit" access to fix this. I don't need that access if someone addresses this issue.

Terraform/Elastic are no longer open source

I wondered if it would be possible to add Yocto Project to the list of LF projects? Someone mentioned to me that it wasn't listed but it is a key LF project.

Whilst our repos are at git.yoctoproject.org, we do have a github mirror for poky, one of our main repos here: https://github.com/yoctoproject/poky

For issues, we bugzilla at https://bugzilla.yoctoproject.org

README.md needs to be reviewed and updated.

I started a project today, i want to do a form with flutter + dart and have seen that velocity_x looks interesting for front so i add its last version to my pubspec.yaml in VSC and 'flutter pub get' it.

Then i import it to my dart code and start running it.

Ended up with this error and am just starting dart so don't really know how to fix it.

I was trying to find the updated numbers and charts graph for ArgoCon24EU and the numbers and charts for 1/1/2024 are the same numbers as 10/2023 ArgoConNA23

From the README page the spreadsheets

spreadsheet with data using range "10/12/2022 - 10/12/2023" Linux Foundation Projects Velocity has the same data for spreadsheet "1/1/2023 - 1/1/2024" Linux Foundation Projects Velocity.
All the projects have the same numbers expect the top 3, take a look at the screen shot you can see from row 5 "Argo" project all projects down have the same data.

So, rather than this being a bug on the scripts themselves, this is a bug in the methodology that they implement. According to the article...

Rather than debate whether to measure high-velocity projects via commits, authors, or comments and pull requests, we use a bubble chart to show all 3 axes of data, and plot on a log-log chart to show the data across large scales.

The problem is that this is a completely biased metric. To understand why, let's look at a hypothetical example. Let's pretend for a moment that there are only two ways to make a HTTP request:

1. Using EveryRequest, which is a library that implements HTTP, FTP, and SCP. Each of those three protocols is maintained by a different author, but within the same codebase; and there is a fourth author that wires it all together in a common interface.
2. Using HTTPRequest, which is a library that just implements HTTP, and that is maintained by a single author. Similarly, there are FTPRequest and SCPRequest (also each with a single maintainer of its own), but we don't use those because we only need HTTP.

Now, let's say that the userbase looks like this, for each:

• EveryRequest: 130 people using it in total; 80 people using it for HTTP, 40 people using it for FTP, 10 people using it for SCP.
• HTTPRequest: 100 people using it for HTTP.
• FTPRequest: 60 people using it for FTP.
• SCPRequest: 20 people using it for SCP.

Now, we get the following data:

• Most users: EveryRequest. This is wrong, because for each individual protocol, HTTPRequest/FTPRequest/SCPRequest are more popular, but their userbase is split between multiple projects.
• Most commits: EveryRequest. It contains all the commits for each protocol, thereby likely having more commits in total than any of the other three projects, even if it implements the same protocols, with the same degree of maintenance, and so on. Therefore, also wrong.
• Most authors: Again, EveryRequest has 4 authors, as opposed to 1 author for each of the other libraries; which, for those other libraries, adds up to 3 since there's nobody who needs to tie the interfaces together. Yet there's the same degree of maintenance (one author per protocol), and thus this result is, again, wrong.
• Most issues: Again, EveryRequest comes out 'on top' because it has more total users than any of the other libraries individually, even if per protocol it has both less users and less issues. Which, again, is wrong. An additional factor here is that EveryRequest may be less reliable, and therefore generate more issues than any of the other libraries, simply because its quality is lower.
• Most PRs: Once again, EveryRequest comes out on top. It gets PRs for all three of the protocols, while each of the other projects only get PRs for the single protocol they implement. Even if the net amount of contributions to those is higher.

In all of the above data points, EveryRequest comes out on top; in all of them, incorrectly so. The reason this happens, is that the wrong unit of measure ("project") is used; a more accurate measurement would have been by feature. How many authors maintain a given feature? How many people use it? How many contributions are received to it?

As it stands, the metrics greatly favour monolithic projects, which are necessarily going to be corporate projects; it's already well-understood that project structure often mirrors the organizational structure of the organization or environment in which it was developed. This means that corporations are used to developing monolithic internal projects, and have simply extended this practice to their open-source projects (which can indeed be seen from the architecture of many of the listed projects).

On the other hand, individual developers are more likely to build smaller, single-purpose projects that can be integrated with other software, and that are often deployed far, far more widely than these "high-velocity" monolithic projects. How many people really use OpenStack, for example? It's primarily used internally at companies for large infrastructure deployments, and that's also where its contributions come from, because it tries to handle everything in that infrastructure in a single project (even if composed of multiple parts).

(There are quite a few other unaddressed questions here, too. Was the project always corporate-backed, or did that only happen after the bulk of the contributions? How many of the contributions are made by third parties, and how many are made by employees of the corporation running the project? How much does the corporation really contribute?)

In other words: the way you're measuring favours corporate open-source projects, and has therefore already decided the outcome of the research before even starting on it. This is already a problem from a research perspective, but it's made worse by the chilling effect this can have on individual open-source contributions (especially when published on the Linux Foundation site!), by making individual contributors feel like the open-source community is no longer 'theirs'. There are real and serious consequences to this.

I would strongly recommend retracting the article and informing press (eg. TechRepublic) of that, or at the very least adding a clear notice at the top that the research is not reliable. As it stands, it's extremely misleading.

EDIT: From a quick glance at the article, it also seems like this data was based entirely on GitHub projects alone, which introduces further bias. There are many other platforms (including self-hosted!) that are often used for maintaining non-corporate projects.

They are no longer open source

https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license
https://www.hashicorp.com/license-faq

Xen is a LF project, see official websites at https://xenproject.org
Xen and its sub-projects are hosted at https://xenbits.xen.org, main development repository for Xen Hypervisor is at https://xenbits.xen.org/git-http/xen.git

For example, in the latest velocity report that we haven't published, the Cilium projects included a forked repo of Linux which jacks up the velocity data imho, we should probably ignore all FORKED repos into the project, e.g,. https://github.com/cilium/linux

Hello,

Zephyr is represented twice in the 1/1/2023-1/1/2024 Linux Foundation Projects data/chart. Also, OpenTelemetry seems to be missing from that chart.

It appears that the OpenTelemetry data may have been subsumed by one of those Zephyr entries.

Create a chart for Linux Foundation projects.
It should be similar to CNCF projects and Top 30 open source projects.

I took a look at the LF projects velocity sheet: https://docs.google.com/spreadsheets/d/1XWFyDLi299Wb-PVWE7s9MpFGN9SDGQOmUUc4VgVVuK8/edit#gid=1169691230

and Sigstore is missing. Any idea how to get it added? We're at github.com/sigstore, and have been an LF project since early 2021.

https://github.com/github isn't really a distinct project in a sense and it can confuse folks as GitHub is closed source

Hey CNCF velocity! I was wondering if there was a plan to generate new data for 2019-2020? It would be really great to see!

In the velocity reports, we report "The y-axis is the total number of pull requests and issues".

From the query, this is determined by the total amount of PullRequestEvents: https://github.com/cncf/velocity/blob/8e1d1c189b65e2544fae7aec43c6381f9e4b4d82/BigQuery/velocity_cncf.sql#L19C18-L19C34.

A PullRequestEvent does not correlate 1:1 with "a PR" in a way a person would interpret a count of PRs, in my opinion. There are two reasonable approaches (merged PRs or opened PRs, strongly preferring merged PRs), neither of which this counts.

Per docs 'The action that was performed. Can be one of opened, edited, closed, reopened, assigned, unassigned, review_requested, review_request_removed, labeled, unlabeled, and synchronize.'. However, in practice I found this doesn't seem to be the case. Looking at a single day across github:

   1916 reopened
 168129 closed
 193220 opened

Even without the other possible events, we at least appear to be double counting PRs?

In the velocity report, it's unclear what constitutes an author and what's the difference between that and contributors as measured by devstats.

I saw the latest chart in this tweet: https://twitter.com/dankohn1/status/1148967017048924162.

Will there be an easy to access spreadsheet like a few years ago? (see https://docs.google.com/spreadsheets/d/1a2VdKfAI1g9ZyWL09TnJ-snOpi4BC9kaEVmB7IufY7g/edit#gid=1169691230)

Lukas, I have been going through all your work. You are doing a great job of documenting everything, I just know that I'm less likely to use the data if I have to sift through everything.,

If you open any of the charts for CNCF Project Velocity, the date in the chart title seems to be hard-coded to "1/1/2022 - 1/1/2023", which doesn't match the title of the spreadsheet. I think the spreadsheet title is correct - for example, this is the current report which seems to be correctly showing the last year from 12 October 2022