# crowd.dev: renamed, but the URLs still point at the old company

> The Linux Foundation's community data platform, which began as a startup acquired in 2024 and now sits inside a larger foundation platform. The repository is a working monorepo with a real development workflow; what has not been updated is the documentation about itself.

**linuxfoundation/crowd.dev** — LFX Community Data Platform (CDP)

- Repository: https://github.com/linuxfoundation/crowd.dev
- Website: https://lfx.linuxfoundation.org
- Stars: 3,368 · Forks: 725
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/linuxfoundation-crowd-dev

## The project was renamed, the links were not

The history is one paragraph and it explains most of the friction in the repository. The project launched as part of a startup, that startup was acquired by the Linux Foundation in April 2024, and the product was renamed from its original name to the community data platform before becoming part of a wider foundation platform. The repository you would clone today therefore carries a title that matches the current name and an ownership that matches the current owner, while several of its instructions do not. The clone command in the readme points at the old organisation's repository, and the contribution guide link does the same. For someone who arrived from a search result rather than from the foundation, that mismatch is the first thing that raises a question, and it is a fair one.

## The readme calls its own documentation out of date

There is a warning marker in the getting started section, and it is blunt: the documentation is outdated and needs to be reviewed. Everything a self-hoster needs is therefore elsewhere. The self-hosting documentation covers the initial setup and the deployment options, of which there are two shapes: an orchestrated deployment for production, and a lighter development environment using containers. A separate integrations guide covers connecting outside systems, and it carries the instruction that matters most for planning, which is that every integration is supported but each one requires you to create your own application. In other words, nothing is plug-and-play: you are registering your own credentials and endpoints for each source, which is a real integration project rather than a configuration exercise.

## What the platform collects, and what it does with it

The stated purpose is data consolidation across the foundation's communities into a single database, serving four named purposes: unification, identity resolution, analysis, and activation. The feature list makes the mechanics concrete. It consolidates the touchpoints a developer has with a company or a brand. It captures data from community platforms, from product channels, and from commercial channels. It cleans that data, matches profiles across the platforms they appear on, and enriches them with third-party data. The output is described as a single view of a developer's engagement, the companies involved, and the journey between them. Read plainly, this is a system for understanding who the contributors are and which organisations they touch, which is useful for support work and is also the kind of system that needs a governance answer before it is populated.

## One command starts the stack, on a single port

The development workflow is a script rather than a document, and the readme gets you to a running application in three commands. Requirements are a current Node runtime, specified as the newest major version, plus a container runtime and its compose tool. You clone the monorepo, change into a scripts directory, and run a CLI subcommand that starts everything. There is a second subcommand for a clean start with hot reloading, which is what you want while editing. A third mode is toggled by an environment variable and brings up the services the insights infrastructure needs, naming three of them: a columnar store, a change data capture service, and a sink connector. With that variable set, the application answers on one port, given in the readme.

```shell
WITH_INSIGHTS=1 ./cli scaffold up
```

## Tags stopped in 2023 while the branch kept moving

The release history is the clearest signal about how this repository is versioned, and the answer is that it mostly is not. Three recent tags exist, all in a four-week window in late 2023: a patch and two minors. The most recent push to the default branch is dated in October 2026. So any dependency or deployment pinned to a tag is pinning to code that predates the current tree by roughly three years, and the version numbers in the tags say nothing about what is deployed. The project is not archived, which means the code is still being changed; it simply is not being cut. For a self-hoster this is the single most important operational fact on the page, because there is no release cadence to plan around.

## The root package has no name and no version

The workspace manifest is private and carries neither a name nor a version, which is the correct shape for a monorepo root that is never published and exists only to hold shared scripts and configuration. It does pin three things precisely. The runtime is declared as a minimum major version of Node, the package manager is pinned to a specific release with an integrity hash appended, and one dependency resolves through the workspace catalogue rather than by version range, so a single entry controls it for every package that uses it. Two version-manager files sit side by side at the root, one for a runtime manager and one for a general tool manager, which suggests the project supports developers arriving with either convention rather than insisting on one.

## Four ways to run tests, and one commit message format

The script list in the root manifest is short and says more about the project's habits than the prose does. There is a plain run for the whole suite, a variant scoped to a single project inside the workspace for when you are working on the server side, a variant that only runs what changed, and a watch mode. Type checking is a separate build invocation rather than part of the test run, so a type error does not show up as a test failure. Linting and formatting both come in pairs, a plain command and a fixing or checking variant. And commit messages are not left to discipline: the manifest includes a commit message linter with the conventional-commits configuration, alongside a configuration file at the root, so the format is enforced by a hook installed at setup rather than by review.

## Conclusion

This platform fits an organisation that already has several communities and wants their contributor data in one place, with identity resolution across platforms. Two things to check before you invest. Read the data-collection description carefully, because the stated purpose is unified analysis and enrichment with third-party data, which is a governance conversation as much as a technical one. And treat the readme as a rough surface: it declares its own documentation out of date, and the self-hosting instructions still live on the old company's domain.

## FAQ

### What is the LFX Community Data Platform?

It is the Linux Foundation's platform for collecting and storing data from across its communities in a single database, for data unification, identity resolution, analysis, and activation. It began as a startup that the Foundation acquired in April 2024, was renamed from its original name, and is now part of the wider LFX platform.

### How do I self-host the crowd.dev platform?

The readme warns that its own documentation is out of date and points to the self-hosting documentation instead. Deployment is available either through an orchestrated container platform for production or through a lighter development environment using containers, and all integrations are supported, though each one requires you to create your own application first.

### How do I run the crowd.dev development environment?

You need a current Node major release, a container runtime and its compose tool, then you clone the monorepo, change into the scripts directory and run the CLI start subcommand. A clean start variant gives you hot reloading, and an environment variable brings up the extra services the insights infrastructure needs, including a columnar store, a change data capture service, and a sink connector.

### Does crowd.dev publish regular releases?

Not recently. The three listed tags are a patch and two minors published within about four weeks in late 2023, while the default branch was pushed in October 2026. The repository is not archived, so the code still changes, but anything pinned to a tag is pinned to code from three years earlier.

## Sources

- [License: Apache-2.0](https://github.com/linuxfoundation/crowd.dev/blob/main/LICENSE)
- [linuxfoundation/crowd.dev on GitHub](https://github.com/linuxfoundation/crowd.dev)
- [Project website](https://lfx.linuxfoundation.org)
- [README](https://github.com/linuxfoundation/crowd.dev/blob/main/README.md)
- [Releases](https://github.com/linuxfoundation/crowd.dev/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/linuxfoundation-crowd-dev