# flutter/devtools: the source of the Dart and Flutter inspector you already use > This repository is the development home of Dart and Flutter DevTools, a performance tooling suite whose install and usage documentation lives on docs.flutter.dev rather than in the README. It is BSD-3-Clause, carries an OpenSSF Scorecard badge, and ships no GitHub releases at all. **flutter/devtools** — Developer tools for Flutter & Dart - Repository: https://github.com/flutter/devtools - Website: https://docs.flutter.dev/tools/devtools - Stars: 1,734 · Forks: 412 - Language: Dart - License: BSD-3-Clause - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/flutter-devtools ## A source repository, not a distribution The README is short and the shortness is the most informative thing about it. What is this? Dart and Flutter DevTools is a suite of performance tools for Dart and Flutter. Getting started points at the documentation site, docs.flutter.dev/tools/devtools, for documentation on installing and trying out DevTools. So the repository is the source, and the install path lives elsewhere. If you arrive looking for a download link you will not find one here, and that is by design rather than an omission. The licence header at the top of the README makes the same point about provenance: the file is Copyright 2025 The Flutter Authors, under a BSD-style licence found in LICENSE or at the Google open source licences page. GitHub records the same identifier, BSD-3-Clause. The two badges are worth reading for what they are. The Build Status badge points at a workflow named devtools, and the OpenSSF Scorecard badge points at the deps.dev project page for flutter/devtools, which is the supply chain security scoring service. For a project whose output is a developer tool distributed to a large user base, having a scorecard entry is a deliberate transparency choice rather than decoration. ## What the root directory says about the project shape Since the README says little, the repository listing carries most of the information. The build is a Dart package project. pubspec.yaml and pubspec.lock sit at the root, alongside analysis_options.yaml for lint configuration, and packages/ for the Dart packages. There is no package.json and no Cargo.toml at the root, so the published surface is Dart rather than JavaScript, which is consistent with a tool for the Dart ecosystem. The developer-facing documentation is unusually extensive and unusually separated. CONTRIBUTING.md covers building and contributing. TESTING.md, DEBUGGING.md, STYLE.md and TRIAGE.md each own one area of the process, and DOCUMENTATION.md covers the docs themselves. Splitting them this way means a contributor working on a flaky test reads one short file rather than a contributing guide with five buried sections. There are also files aimed at tooling rather than people. AGENTS.md and CLAUDE.md sit at the root alongside .agents/ and .gemini/ directories and CODEOWNERS, which describes a project that expects automated coding assistants to work in the repository and has written rules for them. That is a deliberate choice worth noting for contributors: the same conventions that bind humans are written down for machines. The rest is plumbing: .github/ for workflows and templates, .vscode/ for editor settings, tool/ for scripts, docs/ for the documentation sources, third_party/ for vendored code, _markdown_images/ for image assets used in Markdown, and devtools_options.yaml plus flutter-candidate.txt as configuration and channel-tracking files. AUTHORS, CODE_OF_CONDUCT.md and BETA_TESTING.md complete the governance set. ## Contributing means building first, not opening a pull request The contribution path is stated in one sentence: contributions welcome, see the contributing page for an overview of how to build and contribute to the project. The emphasis on build is the point. This is an application, not a library. It has a UI, a serving model and a dependency on a running Dart or Flutter process, so there is nothing to contribute to without building it and running it against a real app. The presence of BETA_TESTING.md at the root suggests the project has a channel where unreleased builds are exercised, and flutter-candidate.txt at the root suggests the repository tracks a Flutter candidate version. Neither is explained in the README, so if you want to test against a pre-release Flutter, those are the files to open. DOCUMENTATION.md matters more than it sounds. Docs for a tool suite are a large part of its usability, and having a dedicated document describing how documentation changes get reviewed means a docs pull request is not judged by the same criteria as a code pull request. For anyone planning to contribute, the practical order is: read CONTRIBUTING.md, get the build working locally, read TESTING.md before writing a test and DEBUGGING.md before filing anything, and treat STYLE.md as binding since it is separated out for a reason. ## Using DevTools means agreeing to Google Terms There is a Terms and Privacy section, and it is not boilerplate for this project. By using Dart DevTools, you agree to the Google Terms of Service, and the Google Privacy Policy explains how data collected from the service is used. That is worth pausing on. A performance tool for Dart and Flutter often connects to a running application and inspects it at runtime, which means it can see program state rather than only your own source. The terms section exists because of that capability. If your organisation has a policy on third party services handling data about internal applications, this is the section to read before you wire DevTools into a workflow that touches production-shaped code. The README directs users to docs.flutter.dev for installation and usage information. None of this is a warning, just a boundary: DevTools is a Google-published tool with Google terms attached, and enterprises evaluating it should know that before they install it rather than after. ## Where this repository is the wrong place to look The first wrong-tool case is expecting a release. The repository has no GitHub releases, so there is no changelog to read at release time and no artefact to pin. Flutter tooling handles getting DevTools to your machine, and that is the path the README defers to. The second is looking here for how a specific DevTools feature works. This repository holds the implementation, not a feature reference. The feature documentation is on docs.flutter.dev, and going to the source for usage questions means reading Dart code that is not written to be read by users. The third is expecting a general Dart IDE. DevTools is described as a performance tooling suite. If you want completion, refactoring and navigation, that is the editor and language tooling, not this repository. For feature documentation and setup instructions, the README directs users to docs.flutter.dev rather than presenting this repository as a distribution channel. ## Conclusion Consult docs.flutter.dev/tools/devtools for the installation and setup steps. Do not look to this repository for a GitHub release to pin: it publishes no GitHub releases. If you want to change DevTools itself, start from CONTRIBUTING.md and the separate TESTING.md, DEBUGGING.md, STYLE.md and TRIAGE.md files at the root, since each of those areas has its own process rather than one shared guide. ## FAQ ### How do I install Dart and Flutter DevTools? The README does not include install steps and directs you to the documentation at docs.flutter.dev/tools/devtools for documentation on installing and trying out DevTools. ### What is the flutter/devtools repository? It is the development home of Dart and Flutter DevTools, described as a suite of performance tools for Dart and Flutter. The published documentation lives on docs.flutter.dev rather than in the repository. ### What licence does flutter/devtools use? A BSD-style licence, recorded as BSD-3-Clause, with the copyright header naming The Flutter Authors and pointing to the LICENSE file. ### Where do I find the contribution process for flutter/devtools? CONTRIBUTING.md at the root, which the README points to for an overview of how to build and contribute. Separate files cover the other areas: TESTING.md, DEBUGGING.md, STYLE.md, TRIAGE.md and DOCUMENTATION.md. ### Are there terms of use for Dart DevTools? Yes. The README states that by using Dart DevTools you agree to the Google Terms of Service, and points to the Google Privacy Policy for how data collected from the service is used. ## Sources - [flutter/devtools on GitHub](https://github.com/flutter/devtools) - [Issues](https://github.com/flutter/devtools/issues) - [License: BSD-3-Clause](https://github.com/flutter/devtools/blob/master/LICENSE) - [Project website](https://docs.flutter.dev/tools/devtools) - [README](https://github.com/flutter/devtools/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/flutter-devtools