---
title: 'OpenLambdaVerse: Serverless Dataset'
url: https://www.emergentmind.com/topics/openlambdaverse
type: topic
---

# OpenLambdaVerse: Serverless Dataset

to=arxiv_search.search  彩神争霸怎么json 200  use_search_engine=true
{"query":"ti:\"OpenLambdaVerse\" OR abs:\"OpenLambdaVerse\"", "max_results": 5, "sort_by": "submittedDate"}
to=arxiv_search.search  彩神争霸有ազjson 200  use_search_engine=true
{"query":"\"OpenLambdaVerse: A Dataset and Analysis of Open-Source Serverless Applications\"", "max_results": 10, "sort_by": "relevance"}
to=arxiv_search.search  彩神争霸能json 200  use_search_engine=true
{"query":"id:2508.01492", "max_results": 5, "sort_by": "relevance"}
OpenLambdaVerse is a publicly released dataset of open-source serverless applications mined from GitHub, focused specifically on repositories that use the **Serverless Framework** and deploy to **AWS Lambda**. It is presented as an updated and more restrictive successor to **Wonderless**, designed to capture a current and cleaner snapshot of the serverless ecosystem as it exists in practice in 2025. Its contribution is not limited to corpus construction: the study also characterizes repository size and complexity, language and runtime choices, trigger structure, maturity proxies, popularity indicators, and security-related metadata, and frames the result as the “most up-to-date serverless application (code) dataset” for this stack [2508.01492].

## 1. Definition, scope, and motivation

OpenLambdaVerse is situated within the Function-as-a-Service and Infrastructure-as-Code ecosystem in which frameworks such as the **Serverless Framework** use YAML configurations to define and deploy APIs, tasks, workflows, and event-driven applications. The motivation is the rapid evolution of this ecosystem: runtimes are deprecated, frameworks change, and developers adopt new patterns and plugins. The dataset was therefore created to update the Wonderless methodology using the current GitHub REST API, apply stronger filtering and curation, focus on the ecosystem segment now centered on AWS, and provide a richer characterization than earlier work, including code size, runtime usage, triggers, maturity proxies, popularity, and security-related metadata [2508.01492].

A central scoping decision is the restriction to **AWS-targeted** projects. The paper justifies this choice by noting that **Serverless Framework v4 deprecated support for non-AWS providers**, making AWS the practical center of gravity for the framework. This gives OpenLambdaVerse a narrower but more internally consistent target than prior multi-provider datasets. A plausible implication is that the dataset is intended less as a universal census of “serverless” and more as a focused empirical resource for the current Serverless Framework/AWS Lambda stack.

The study also positions itself against a common assumption that existing serverless datasets remain sufficient over time. OpenLambdaVerse argues instead that up-to-date empirical evidence is necessary because the underlying development ecosystem changes quickly. In that sense, the dataset is both a descriptive artifact and a methodological intervention: it updates repository-mining practice for a changing platform landscape.

## 2. Construction pipeline and curation logic

The collection pipeline was run on **April 24, 2025** and begins by identifying repositories that contain at least one `serverless.yml` file, the main Serverless Framework configuration and deployment descriptor. The process is multi-stage and deliberately aggressive in excluding repositories that are not intended to represent real open-source applications [2508.01492].

| Pipeline stage | Result |
|---|---|
| Initial `serverless.yml` collection | **34,320 configuration file URLs** |
| Remove URLs in example, test, or demo directories | **25,395 URLs** |
| Remove duplicate URLs within the same repository | **20,144 URLs** |
| Remove official `serverless` and `serverless-components` repositories | **20,080 URLs** |
| Remove unlicensed repositories | **4,080 repositories** |
| Remove forks, shallow projects, inactive projects, and toy projects | **816 repositories** |
| Restrict to AWS as provider | **668 repositories** |
| Clone main branches | **51 GB** aggregate raw size; **6 GB** compressed release size |

The metadata extraction step parses `serverless.yml` and queries GitHub’s REST API for plugins, runtimes, events, provider, size, forks, stars, topics, primary language, archived/disabled/fork flags, bytes per programming language, contributors, private vulnerability reporting, tags, last commit date, open issues, watchers, and license. The resulting metadata is stored as **JSONL**, one object per repository [2508.01492].

Several filters encode specific repository-mining assumptions. A repository is considered **shallow** if it is **< 100 KB**. A project is considered **inactive** if it has not been updated in the last **24 months**. Toy projects are filtered when their name, description, or topics contain keywords such as `example`, `tutorial`, `demo`, `sample`, `starter`, `playground`, `hello-world`, `test`, `template`, `learn`, `workshop`, `exercise`, `skeleton`, `boilerplate`, `mock`, `poc`, or `guide` [2508.01492].

The paper also documents GitHub API constraints as part of the methodology. GitHub code search can find files only if they are **smaller than 384 KB**; authenticated non-enterprise users are limited to **5,000 requests/hour**; and the search endpoint is limited to **10 requests/minute**, so the implementation uses **7-second sleep timers** between search requests. The authors state that the 384 KB limit is unlikely to matter much because large YAML files are rare, and they observed only three files in the 86–168 KB range [2508.01492].

## 3. Repository size, code composition, and architectural heterogeneity

OpenLambdaVerse emphasizes that real-world serverless applications in this ecosystem are often not pure serverless microservices. Instead, many are embedded in larger applications that contain substantial non-Lambda code, including PHP frontend or backend logic. This point appears in the paper’s interpretation of both line-count and byte-count statistics and is important for avoiding a misleadingly narrow picture of serverless architecture [2508.01492].

Using **CLOC**, the study reports a mean of **20,022 LOC per repository**. The distribution is highly skewed toward smaller repositories: **53.82%** of repositories have **1,000 LOC or less**, and **9.75%** have **100 LOC or less**. Across the dataset as a whole, there are **13,355,275 LOC** in **69,036 files**. By total LOC, **PHP** accounts for **6,163,832 LOC (46.15%)**, **JavaScript** for **5,081,974 LOC (38.05%)**, **TypeScript** for **1,713,025 LOC (12.83%)**, and **Python** for **179,825 LOC (1.35%)**. Smaller shares are reported for **Rust**, **Go**, **C#**, **Cython**, **Java**, **Ruby**, **PowerShell**, and **Other** categories [2508.01492].

The byte-based analysis follows the same pattern. Total repository bytes are **693,116,497**, of which **PHP** contributes **362,887,947 (52.36%)**, **JavaScript** **247,084,664 (35.65%)**, **TypeScript** **64,327,098 (9.28%)**, and **Python** **7,814,919 (1.13%)**. The paper explicitly cautions that automated language analysis is imperfect where serverless functions coexist with larger non-serverless codebases. This suggests that repository-wide language prevalence should not be equated directly with Lambda handler implementation language [2508.01492].

Repository size is likewise broad: the minimum is **100 KB**, the maximum **462 MB**, the median **1.03 MB**, and the standard deviation **31 MB**. Self-labeling through GitHub topics also reflects a heterogeneous ecosystem. The most common topics are `serverless` (**92**), `aws-lambda` (**59**), `aws` (**42**), `serverless-framework` (**36**), `lambda` (**36**), `nodejs` (**32**), `typescript` (**30**), `cvs-project` (**17**), `hacktoberfest` (**16**), and `dynamodb` (**15**) [2508.01492].

A common misconception is that a repository using the Serverless Framework is necessarily a compact, Lambda-centric codebase. OpenLambdaVerse argues against that view empirically. The corpus includes many repositories in which serverless functions coexist with broader application logic, making the dataset relevant not only to FaaS studies narrowly construed but also to studies of hybrid application structure.

## 4. Runtimes, plugins, and trigger models

Because repository-wide language statistics can misrepresent the code that actually runs on Lambda, the paper treats **runtimes** as the more direct indicator of function implementation choices. By runtime count, **nodejs** dominates with **426 repositories (73.58%)**, followed by **python** with **94 (16.23%)**, **provided (OS-only)** with **20 (3.45%)**, **java** with **16 (2.76%)**, **go** with **12 (2.07%)**, **ruby** with **7 (1.21%)**, and **dotnet** with **4 (0.69%)**. The authors note that **provided (OS-only)** runtimes are used for languages not directly supported by Lambda, such as Go and Rust, and that Go’s presence is shaped partly by AWS support for Go 1.x until January 2024 [2508.01492].

Plugin usage shows a tooling ecosystem centered on local development, packaging, and deployment ergonomics. The most common plugins are `serverless-offline` (**270**), `serverless-webpack` (**91**), `serverless-dotenv-plugin` (**87**), `serverless-plugin-typescript` (**80**), `serverless-python-requirements` (**71**), `serverless-prune-plugin` (**49**), `serverless-domain-manager` (**42**), `serverless-esbuild` (**31**), `serverless-bundle` (**25**), `serverless-iam-roles-per-function` (**25**), and `serverless-dynamodb-local` (**24**). The paper interprets `serverless-offline` as evidence of the importance of local emulation for AWS Lambda and API Gateway workflows. It also notes that `serverless-iam-roles-per-function` appears in only **25 projects (3.59%)**, which suggests that fine-grained governance is not consistently adopted [2508.01492].

Trigger analysis indicates that the corpus is strongly API-oriented. The `http` trigger accounts for **1547 triggers (62.43%)** and appears in **51.05%** of repositories; `httpApi` accounts for **529 triggers (21.35%)** and appears in **23.20%** of repositories. Together, `http` and `httpApi` account for **83.78% of all triggers**, and **73.20% of repositories** use at least one of those two trigger types. Scheduled execution is the next major category: `schedule` contributes **199 triggers (8.03%)** and appears in **14.37%** of repositories. Other trigger types, including **SQS**, **SNS**, and **S3**, are present in roughly the **2–4%** repository range [2508.01492].

The study further reports that **88.47%** of projects have between **1 and 4 triggers**, and that the correlation between number of triggers and LOC is **0.05**, interpreted as negligible. This is methodologically important: trigger count should not be treated as a proxy for implementation complexity. A plausible implication is that even repositories with relatively simple event surfaces may contain substantial internal codebases, while repositories with several triggers are not necessarily larger systems.

## 5. Maturity, popularity proxies, and security posture

OpenLambdaVerse uses several repository-level indicators as proxies for project maturity and community engagement. The analysis of creation year finds **no strong sign of declining popularity yet**, and the apparent drop in 2025 is attributed to the year being incomplete. This is a limited claim about repository creation patterns within the sampled corpus rather than a general claim about the entire serverless market [2508.01492].

The popularity and activity indicators reveal a mixed ecosystem. The average number of contributors per project is **5**, while **34.58%** of repositories are driven by a **single contributor**. The average number of open issues is **7**, and **43.71%** of projects have **zero open issues**. Meanwhile, **38.62%** of repositories have been **forked at least once**. The paper treats these figures as signs of coexistence between small, solo-maintained projects and repositories with more substantial community engagement [2508.01492].

The most explicit security-related finding concerns GitHub’s **private vulnerability reporting** feature. Only **98 repositories (14.67%)** have it enabled. The paper interprets this as evidence that security best practices are not widely implemented in the sampled serverless projects. At the same time, it qualifies the point carefully: repository metadata alone does not determine whether cloud-side security settings are configured outside the repository. Thus, absence of code-level evidence does not necessarily prove insecurity. The study nonetheless argues that failing to version and track such settings in the repository can itself be risky [2508.01492].

This dual interpretation is important. OpenLambdaVerse does not claim that the ecosystem is broadly insecure in an absolute sense; rather, it shows that visible repository-level security signals are sparse. For infrastructure studies, this distinction matters because it separates what can be empirically observed in version-controlled artifacts from what may exist in external cloud consoles or organizational processes.

## 6. Comparative position, limitations, and research significance

OpenLambdaVerse is explicitly framed against prior serverless datasets. **Wonderless** collected **1,877** GitHub projects using the Serverless Framework across multiple cloud providers. **Eismann et al.** analyzed **89** applications in 2021. **AWSomePy** covered **145** Python-only Serverless Framework applications on AWS. OpenLambdaVerse, by contrast, consists of **668** GitHub repositories from 2025, restricted to the Serverless Framework and AWS [2508.01492].

The comparative findings are selective but informative. For runtimes, **Node.js** and **Python** remain dominant across studies: OpenLambdaVerse reports **nodejs 73.6%** and **python 16.2%**, compared with **Wonderless 72.2%** and **19%**. **Java** appears at around **2.8%** in both OpenLambdaVerse and Wonderless, while Eismann and Datadog report much higher Java usage (**12%** and **10%** respectively); the paper suggests that this may be due to private repositories or Terraform-managed deployments in Datadog’s dataset. It also notes that **provided/custom runtimes** appear more often in OpenLambdaVerse, possibly reflecting migration away from deprecated native runtime support [2508.01492].

The paper is equally explicit about threats to validity. External validity is limited by **public-repository bias**, by **framework/provider specificity** to the Serverless Framework and AWS Lambda, and by the intentional **AWS-only scope**. Internal validity is limited by possible **filtering errors** in the heuristic exclusion of forks, shallow projects, inactive projects, and toy projects; by the fact that absent security metadata does not prove insecurity; and by the possibility that **automated language inference** mischaracterizes repositories where serverless functions coexist with substantial non-serverless code [2508.01492].

Within the broader serverless literature, OpenLambdaVerse occupies a corpus-building and characterization role rather than a systems role. Domain-specific work such as the distributed ROOT/RDataFrame execution engine on AWS Lambda for high-energy physics demonstrates how serverless infrastructures can be used to run real scientific workloads [2206.00942]. OpenLambdaVerse addresses a different problem: it provides a reproducible, well-filtered view of how open-source Serverless Framework/AWS applications are actually structured, which technologies they use, how they are triggered, and what their visible repository practices imply about maintenance and security [2508.01492].

The paper’s overall significance is therefore both descriptive and practical. Descriptively, it shows that the contemporary Serverless Framework/AWS ecosystem is dominated by **Node.js**, heavily oriented toward **HTTP-triggered** applications, and frequently embedded in larger repositories rather than isolated into pure serverless microservices. Practically, it surfaces the importance of plugin ecosystems, the effects of runtime deprecation and provider support changes, and the weak uptake of visible security mechanisms. For researchers, it offers a more current and more curated corpus than Wonderless and a basis for studying modern serverless architecture patterns, runtime migration, security practices, and maintainability [2508.01492].

Source: https://www.emergentmind.com/topics/openlambdaverse