Open source / Flutter
Open source in apps: how do you use packages and share code?
A ready-made package can save weeks of work, but it also becomes part of an app you must maintain. Open source gives you access to the code and the ability to extend it. A good choice still requires checking licensing, limitations and the library's behaviour in your product.
1. Open code also has terms of use
Open source means more than a public repository. A licence defines rights to use, modify and distribute code. Being able to read files on GitHub alone does not make a project open source.
For example, the MIT licence allows use and modification, including commercial use, provided the copyright notice and permission notice are kept in copies or substantial portions of the code. It provides no warranty. Check the terms for each library and its dependencies; do not apply MIT terms to every publicly accessible project.
2. Choose a package for the problem you actually have
Start with the app's needs: required features, platforms and environment constraints. A package with an extensive API is not always better than a small library solving one problem. How easily you can test, update or replace it also matters.
Read the documentation, changelog and issue reports. Check tests and failure handling. Download counts can help identify popular options, but do not prove quality or suitability. Infrequent releases do not necessarily mean abandonment either: a small, stable package may simply need fewer changes.
3. disk_kit — connecting Flutter with the system
At Dark Fox, we publish disk_kit: a Flutter package for macOS disk management with a Dart API and native Swift implementation. Besides device discovery, volume operations and formatting, it supports copying with progress reporting, IMG and hybrid ISO writing, and preparation of Windows UEFI and macOS installation media. It is released under the MIT licence.
Release 1.2.3 runs on macOS 12+ outside App Sandbox, using Flutter 3.27+ and Dart 3.6+. Windows and Linux implementations remain planned. Windows installation media is prepared on a Mac, and splitting large WIM files requires a separately supplied wimlib. Check features and requirements for the specific release.
The optional disk_kit_macos_extensions separates additional tools from the core package. It integrates formatting existing NTFS and ext2/ext3/ext4 partitions and checking volume access. It requires separately supplied mkntfs or mke2fs programs; it does not supply drivers or automatically enable macOS read and write support for those file systems.
Storage operations also illustrate the division of responsibilities: the package performs an operation, while the app must clearly show the selected disk and obtain confirmation before formatting. disk_kit does not create automatic backups. Testing these features requires a separate device with disposable data.
4. Dependencies need an update plan
In Dart or Flutter, pubspec.yaml describes dependencies and allowed versions, while pubspec.lock records the resolved package versions. Commit the app's lock file so the team uses the same dependency set.
Treat an update as a deliberate change: read the changelog, check SDK requirements, run tests and build the app on target platforms. If a package interacts with the operating system, a Dart test alone does not verify its native implementation. Also test missing permissions, device disconnection and operation failures.
5. When should you publish your own package?
A good candidate is a module with a clear purpose that can be used without knowing the rest of your app. Extracting it encourages a clear API and separation between technical capabilities and product-specific rules. Not every piece of code needs its own package.
Before publishing, prepare a licence, installation instructions, a working example, tests and a description of limitations. Check that the repository contains no secrets or client data. Explain how to report bugs and which platforms were actually tested. Clearly distinguish promised features from those available today.
6. Open source does not rule out a paid app
Open source describes rights to code, not an obligation to make the product free of charge. You can sell apps using open libraries, as well as open source software itself. Licence terms are a separate matter: they define distribution, attribution and sharing modifications, among other things.
We release disk_kit and disk_kit_macos_extensions under MIT. This licence allows use in paid apps and does not require opening your entire product simply because it uses the packages. Required copyright and licence notices must be preserved. Other dependencies and bundled tools, such as wimlib, have their own terms that need separate review.
A paid product can offer a finished interface, consistent workflows, integrations, updates and support while using a shared open foundation. This lets you share a technical solution while retaining a business model. Do not assume MIT rules apply to all open source licences — obligations vary.
7. Contributing to open source starts with a specific problem
Sharing code lets others solve similar problems without rebuilding the same integration. Publishing a small, independent package also creates space for shared fixes and examples. In disk_kit, separating the core API from optional extensions makes it possible to use the required features without imposing the full dependency set.
Helping does not require a large pull request. A reproducible bug report, a small example, a documentation fix or a regression test can make maintenance much easier. Before making a major change, check contribution guidelines and discuss its scope with the maintainers.
For a product team, open source is a way to collaborate and reuse code. It helps when a chosen package solves a real problem and the team understands its limitations and can maintain the integration.
Package selection and integration are also part of building and developing Flutter apps.
Documentation for your next steps
Use installation instructions that match the versions in your project. The sources below cover these topics in more detail.