DEV Community: Mohammed Khan

The cost of open source

Mohammed Khan — Thu, 08 Oct 2026 08:44:16 +0000

Open source is free to use. It has never been free to make.

Open source sits underneath almost every piece of software shipped today. Frameworks, databases, build tools and the libraries inside them are, in large part, written and maintained by people who were never paid to do so.

The conversation around open source tends to focus on its benefits: faster innovation, shared infrastructure and transparency. Far less attention is paid to what publishing costs the people who do it. That cost is rarely financial, and few maintainers expect it to be. It is measured instead in control, in attribution, and in the time and energy required to sustain something that others depend on.

This article examines those costs, why developers continue to accept them, and what can be done to make them more manageable.

What does a developer give up when they give their work away?

Part One: Loss of Control Over Use

Software is written with an intended purpose. A license, however, governs permission, not purpose. Once code is published, its author has no say in how it is applied.

A scraping library built for price comparison can power ticket-scalping bots. An automation tool designed for customer support can be repurposed to send spam. A speech-synthesis feature intended to let people reply in their own voice can be used to imitate someone else's.

For many maintainers, this is the most personal cost of publishing: becoming an unwilling participant in uses they would have declined. There is no approval step and rarely any notification. Discovery tends to be accidental.

The tension occasionally surfaces in public. In January 2022, the author of the widely used JavaScript packages colors and faker deliberately published broken releases, citing frustration that large companies relied on his unpaid work. The response was widely criticised and disrupted a large number of downstream projects. The grievance behind it, however, was one many maintainers recognised.

Part Two: The Erosion of Attribution

For most contributors, attribution is the primary return on their work. It underpins professional reputation, demonstrates competence to employers and clients, and is often the only recognition for work done unpaid. Its loss is therefore felt disproportionately.

Permissive licenses such as MIT ask for very little: chiefly, that the copyright and license notice be preserved. Even so, several patterns are common:

Rebranded forks. The same code under a new name and logo, with the original commit history collapsed into a single "initial commit".
Repackaged "premium" products. Open source dashboards and starter kits, lightly restyled and sold on template marketplaces without reference to their origin.
Installation and support services. Third parties charging businesses to deploy a free project, presenting it as a proprietary platform, while support requests flow back to the original maintainer.
Absorption into AI models. Public repositories have been used to train code-generation models that can reproduce familiar patterns without the accompanying license or author. The legal position remains under dispute. The attribution gap does not.

None of these practices affect whether the code works. They do, however, sever the connection between the work and the person responsible for maintaining it, who is usually the party the project most depends on.

Part Three: Premium Functionality Without a Price

The costs above are most acute for one category of project: the one that offers, for free, capabilities that are elsewhere sold as commercial products.

Agent orchestration, workflow automation, observability, voice synthesis and evaluation tooling all have established paid markets. When an independent developer publishes a working alternative, three effects tend to follow.

Credibility suffers. Free software is often assumed to be a prototype or an abandoned experiment. The same software can appear more credible once someone else attaches a price to it.

Others monetise it. Consultants and resellers package, install and bill for it. Most licenses permit this. For the author, it can mean watching their unpaid work become someone else's recurring revenue.

Large providers adopt it at scale. This dynamic has shaped much of the last five years of open source licensing:

Project	What happened
Elasticsearch	Moved away from Apache 2.0 in 2021, citing cloud providers offering it as a managed service. Later added the AGPL back as an option.
Redis	Switched from BSD to the source-available RSAL and SSPL in 2024. The Linux Foundation backed a community fork, Valkey. Redis 8 returned with an AGPL option in 2025.
Terraform	HashiCorp moved to the Business Source License in 2023. The community forked it as OpenTofu.

Each decision addressed the same problem: how to prevent others from profiting from a project without contributing back. Each also carried its own cost, in forks, lost trust and divided communities.

If organisations with legal teams and boards have struggled to resolve this, individual maintainers are considerably less well placed to do so.

Part Four: Expectation, Noise and Maintainer Fatigue

Unpaid support obligations

A useful project attracts issues. Many are constructive. A significant share are not: terse reports, requests for timelines, and questions about whether the project has been abandoned. Some come from users who paid a third party for an installation and now expect the original author to support it.

No contract exists in any of these cases. The expectation forms regardless.

Automated noise

A newer cost is the volume of AI-generated bug reports: submissions that appear credible, reference functions that do not exist, and consume hours of review before they can be dismissed.

The curl project illustrates the scale of the problem. It ended its bug bounty in January 2026, after more than six years, because fabricated reports had begun to outnumber genuine ones. From 1 July to 3 August 2026, its security team paused vulnerability intake altogether. One of the most widely deployed libraries in the world, maintained by a small volunteer team, had to close its inbox to remain sustainable.

Usage without support

In February 2023, the maintainer of core-js, a library downloaded tens of millions of times a week and present on a large share of the most visited websites, published an account of his financial difficulties. Early donations had amounted to roughly $57 a month, and adding a funding link had, by his account, drawn hostile responses.

The pattern is consistent: the more widely a project is used, the more its maintainer is relied upon, and the less visible that maintainer becomes.

Fatigue as a security risk

In 2024, a backdoor was discovered in xz, a compression library present in a large number of Linux distributions. It was not the result of a technical breach. The attacker spent years building trust with an overextended maintainer until they were granted commit access.

Maintainer fatigue is therefore not only a personal cost. When the people sustaining critical software run out of capacity, everyone who depends on it inherits the risk.

Part Five: Why Developers Continue to Publish

Given these costs, it is reasonable to ask why so many developers continue to release valuable work for free. The answer is that the other side of the ledger is equally real.

Cost	Return
Loss of control over how code is used	Reach far beyond what one developer could achieve alone
Attribution that is removed or overlooked	A public body of work that demonstrates capability directly
Premium features monetised by others	Clear evidence that the work has commercial value
Unpaid support and automated noise	Bug reports, fixes and ideas from a wider community
Mistakes visible to everyone	Security that can be audited rather than assumed
Time and energy	Freedom to build without commercial constraints

Open source also offers something few commercial products can: freedom from lock-in. A subscription business benefits when leaving is difficult. An open project has no such incentive. Users can run it on their own infrastructure, keep their data in-house, inspect every line and migrate whenever they choose.

Finally, there is reciprocity. Every developer builds on open source written by others. Publishing is, for many, a way of contributing back to the foundation they rely on.

Part Six: Managing the Costs

These costs cannot be eliminated, but they can be chosen deliberately rather than discovered later.

Select a license intentionally

MIT is often chosen by default. That is a reasonable choice, provided its implications are understood.

License	What others may do	What it protects
MIT / Apache 2.0	Almost anything, including closed commercial products built on the code	The copyright notice
GPL-3.0	Use and sell it; distributed modifications must remain open	Improvements to distributed software
AGPL-3.0	As GPL, with network use of a modified version also counting as distribution	Modifications offered as a hosted service

None of these prevent others from charging for installation or support. Each defines clearly what must be returned.

Make attribution durable

Include the author's name in the LICENSE and a NOTICE file, in the application's About screen and in API metadata. Attribution recorded in several places is considerably harder to remove than attribution recorded in one.

Protect the name

The code may be open while the project's name and logo are not. Trademarks are how many established projects prevent forks from presenting themselves as the official distribution.

Document expectations

A CONTRIBUTING guide, a SECURITY policy and a short support statement convert implicit expectations into explicit ones. A single line, such as "issues are reviewed weekly and paid support is not offered", can prevent a great deal of friction.

Provide a route for support

Sponsorship links rarely produce significant income. They do give users who value the work a practical way to contribute to its upkeep.

Set limits

Declining features, deadlines and demands is part of sustainable maintenance. curl's five-week intake pause demonstrates that even critical projects can, and sometimes must, step back.

A Case in Point: Obsidian AI

A brief disclosure: this subject is not abstract for me.

For the past seven months I have been developing Obsidian AI, an open source, self-hosted platform for building and orchestrating AI agents. It falls squarely into the category described in Part Three, offering capabilities that are typically sold as commercial products.

Capability	Typical commercial equivalent
Agents across OpenAI, Anthropic, Gemini, Ollama and OpenRouter	Separate per-provider integrations
Multi-agent teams with delegation between agents	Enterprise agent platforms
Visual workflows with conditions, approvals and loops, including n8n import	Workflow automation subscriptions
Evaluation suites, prompt optimisation, tracing and per-agent cost reporting	Observability and evaluation licences
Long-term memory, retrieval-augmented generation and Markdown knowledge vaults	Knowledge management add-ons
WhatsApp agents with local transcription, voice replies and voice cloning	Metered messaging and voice APIs
A Docker sandbox and isolated execution for user-defined tools	Hosted code execution services

The project now comprises roughly 62,000 lines of code and 173 API endpoints, and runs entirely on the user's own infrastructure. It has also appeared on third-party sites as a paid installation service.

Several of the costs discussed above apply directly. The voice cloning feature was designed so that users could respond in their own voice, but its use cannot be controlled once published. The WhatsApp integration avoids the need for a business account by relying on an unofficial library, a trade-off that every deployment inherits. Documentation has not kept pace with development. And when a weakness was identified in how user-defined tools were executed, it was resolved in public, where its prior existence was equally visible.

These considerations informed the choice of license. Obsidian AI is released under the AGPL-3.0. Anyone may install, host, customise and charge for services around it. Modified versions, including those offered as hosted services, must remain open, and their users are entitled to the source.

For those offering it commercially to clients, the request is a simple one: be transparent that the underlying software is open source, retain the attribution, and contribute improvements back upstream.

Conclusion

Open source remains one of the most significant achievements of the software industry. It is not, however, without cost. That cost is borne in control, attribution and energy, largely by individuals, and is seldom discussed.

Developers considering publishing valuable work should do so, but with a clear understanding of what they are accepting, and with deliberate choices about which costs they are prepared to carry.

Open source has never been free. Someone always pays. The question is whether they chose to.

Links:

Obsidian AI: github.com/sup3rus3r/obsidian-ai
Previous article: What If Full-Stack Features Were Installable?
Sponsor the project: GitHub Sponsors

Sources: curl's 2026 reporting pause, the core-js funding post, Redis returning to the AGPL.

What If Full-Stack Features Could Be Installed Like Packages?

Mohammed Khan — Sat, 12 Sep 2026 16:12:26 +0000

Building a Full-Stack Module Registry for NextAPI

Modern full-stack development has become remarkably good at reusing individual pieces of software.

We have package managers for JavaScript and Python. We have component libraries for frontend applications. We have frameworks for APIs, ORMs for databases, authentication libraries, SDKs, UI systems, and countless integrations.

Yet when it comes to building an actual application feature, developers still spend a significant amount of time connecting all of those pieces together.

A package might give you a React component.

Another package might give you a Python library.

Another might provide a database abstraction.

But the application developer still has to create the page, expose the API, configure authentication, create the database structure, add navigation, install dependencies, configure environment variables, and connect everything together.

This raises an interesting question:

What if a complete full-stack feature could be packaged and installed in the same way we install a library?

Not just the frontend.

Not just the backend.

The entire feature.

That is the problem I set out to solve with the NextAPI Module Registry.

The idea behind NextAPI modules

A NextAPI module is a reusable, full-stack application capability.

Instead of thinking about a module as a collection of components or functions, a module can contain everything required to introduce a feature into an application.

A module can provide:

Frontend pages
Frontend routes
Backend routers
API endpoints
Database resources
Functions
Dependencies
Environment variables
Authentication requirements
Navigation
Other module dependencies

The important part is that these pieces are not treated as unrelated files.

They are part of one installable unit.

┌─────────────────────────────────────┐
│             NextAPI Module          │
├─────────────────────────────────────┤
│                                     │
│  Frontend                           │
│  ├── Pages                          │
│  ├── Routes                         │
│  └── Navigation                     │
│                                     │
│  Backend                            │
│  ├── Routers                        │
│  ├── API endpoints                  │
│  └── Server logic                   │
│                                     │
│  Database                           │
│  └── Module data                    │
│                                     │
│  Functions                          │
│  ├── Provides                       │
│  └── Uses                           │
│                                     │
│  Dependencies                       │
│  ├── Modules                        │
│  ├── npm                            │
│  └── Python                         │
│                                     │
│  Configuration                      │
│  └── Environment variables          │
│                                     │
└─────────────────────────────────────┘

This changes what we mean by reusable software.

A component is reusable.

A library is reusable.

A module is a reusable application capability.

The NextAPI Module Registry

The module system is built around a registry.

The registry provides a central place where modules can be published, discovered, versioned, and consumed by applications.

This is similar to the role package registries already play in software development.

For example, JavaScript developers are familiar with workflows such as:

npm install package-name

The package manager retrieves the package and makes it available to the project.

The NextAPI workflow is conceptually similar:

nextapi add profile-page

The difference is what is being installed.

Instead of installing a library that the developer then has to integrate, the developer is adding a complete application capability.

After adding modules, the application can be synchronized:

nextapi sync

The synchronization process resolves the modules required by the application and integrates them into the NextAPI project.

This creates a registry specifically designed around full-stack application composition.

Why not just use npm?

This is an important distinction.

NextAPI modules are not intended to replace npm packages.

npm solves a different problem.

A JavaScript package might provide:

React component
Utility function
SDK
State management library
UI library

A Python package might provide:

Database client
Authentication library
AI SDK
Utility library

These are useful building blocks, but they do not necessarily know anything about the structure of the application consuming them.

A NextAPI module operates at a higher level.

For example, an AI module could contain:

AI Module
│
├── Frontend
│   └── /ai
│
├── Backend
│   └── /api/ai
│
├── Database
│   └── conversations
│
├── Functions
│   ├── send_message
│   └── create_conversation
│
├── Dependencies
│   ├── npm packages
│   └── Python packages
│
└── Environment
    └── AI_API_KEY

The developer is not simply installing an AI library.

They are installing an AI feature.

The distinction is the foundation of the module architecture.

What is a NextAPI module?

A module is essentially a self-contained unit that describes both its implementation and how that implementation integrates with a NextAPI application.

A simplified module structure could look like:

my-module/
│
├── module.json
│
├── frontend/
│   ├── pages/
│   └── components/
│
├── backend/
│   ├── router.py
│   └── ...
│
└── ...

The most important file is the module manifest:

module.json

The manifest acts as the contract between the module and the NextAPI runtime.

It tells NextAPI what the module provides, what it requires, and how it should be integrated.

A module manifest can describe things such as:

Module identity
       │
       ├── Name
       ├── Version
       └── Namespace
       │
       ▼
Compatibility
       │
       └── NextAPI version
       │
       ▼
Dependencies
       │
       ├── Modules
       ├── npm
       └── Python
       │
       ▼
Application integration
       │
       ├── Frontend
       ├── Backend
       ├── Database
       └── Functions
       │
       ▼
Configuration
       │
       └── Environment variables

This machine-readable description is what allows the CLI and registry to understand a module without requiring every integration step to be manually implemented by the application developer.

Frontend integration

One of the major differences between a conventional package and a NextAPI module is that a module can contribute directly to the application's frontend.

A module can declare the routes it provides.

For example:

{
  "frontend": {
    "routes": [
      {
        "path": "/profile",
        "protected": true,
        "label": "Profile"
      }
    ]
  }
}

The module is effectively saying:

I provide a profile feature, and that feature has a /profile route.

The application does not need to independently know how that feature should be represented.

The module declares the information required by the application.

This also makes the module system useful for application navigation.

A module can describe the route and associated navigation information, allowing the application shell to incorporate the feature when the module is installed.

Instead of manually modifying several unrelated parts of the application, the feature travels with its integration metadata.

Backend integration

A full-stack feature also needs a backend.

NextAPI modules can provide backend functionality through FastAPI routers.

For example:

{
  "backend": {
    "router": {
      "module": "backend/router.py",
      "attr": "router",
      "prefix": "/profile"
    }
  }
}

The module contains the backend implementation.

For example:

from fastapi import APIRouter

router = APIRouter()

@router.get("/")
async def get_profile():
    ...

NextAPI can then integrate that router into the application's backend.

The module therefore has a clear boundary:

NextAPI Application
       │
       ├── Core backend
       │
       └── Installed modules
              │
              ├── Profile router
              ├── AI router
              ├── Analytics router
              └── Billing router

Each module can contribute backend functionality without requiring the entire application backend to be manually rewritten around it.

Database integration

Frontend and backend code are only part of a full-stack feature.

Many features require persistent data.

This is where the module architecture goes beyond a conventional component or library system.

A module can declare its database requirements and maintain data belonging to that module.

For example:

Analytics Module
       │
       └── Analytics data

Notifications Module
       │
       └── Notification data

AI Module
       │
       └── Conversation data

The module boundary therefore extends into the data layer.

This matters because a module should ideally be capable of being developed and maintained independently.

If a developer installs an analytics module, they should not have to manually construct the database structure that the module requires.

The module should describe what it needs.

The framework can then integrate those requirements into the application.

Functions and capabilities

One of the more interesting parts of the architecture is the function system.

Modules can expose functions and consume functions provided by other modules.

For example, a module could declare:

{
  "functions": {
    "uses": [
      "auth.get_current_user",
      "profile.get_display_name"
    ]
  }
}

Another module can provide those capabilities.

This creates a capability-oriented relationship between modules.

Instead of thinking:

Module A imports internal code from Module B

the relationship becomes:

Module A
   │
   │ requires
   ▼
profile.get_display_name
   ▲
   │ provides
   │
Module B

This is useful because the consumer does not necessarily need to know how the provider implements the function.

It only needs the capability.

That creates the possibility of building modules that communicate through stable contracts rather than tightly coupling themselves to each other's internal source code.

Module dependencies

Modules can also depend on other modules.

Imagine an AI workspace that requires a user profile system.

The AI module can declare that dependency:

{
  "requires": {
    "modules": [
      "profile-page@^1.0.0"
    ]
  }
}

The developer can then install the AI workspace without manually determining every dependency it requires.

The dependency graph might look like:

AI Workspace
      │
      ├── Profile
      │     │
      │     └── Authentication
      │
      └── AI Provider

The module system can resolve this graph when synchronizing the application.

This becomes increasingly important as the ecosystem grows.

A module can build on another module without forcing every application developer to understand the entire dependency tree.

npm and Python dependencies

NextAPI modules can also declare dependencies from the underlying ecosystems.

For example, a frontend module may require an npm package:

{
  "dependencies": {
    "frontend": {
      "npm": {
        "react-markdown": "^9.0.0"
      }
    }
  }
}

A backend module may require a Python package:

{
  "dependencies": {
    "backend": {
      "pypi": {
        "anthropic": "^0.40.0"
      }
    }
  }
}

This creates a dependency hierarchy:

Application
     │
     ▼
NextAPI Module
     │
     ├── Module dependencies
     │
     ├── npm dependencies
     │
     └── Python dependencies

The module therefore sits above the existing package ecosystems rather than attempting to replace them.

Environment variables

Application capabilities frequently require configuration.

An AI module might require an API key.

A payments module might require merchant credentials.

An email module might require SMTP configuration.

These requirements can be described by the module.

For example:

{
  "env": {
    "backend": [
      {
        "key": "AI_API_KEY",
        "required": true,
        "secret": true
      }
    ]
  }
}

The module now declares an important part of its runtime requirements.

This is another example of why a module is more than a package.

The module is describing the complete environment required by a feature.

Namespaces and isolation

Once you have a public registry, naming becomes important.

Different developers may want to create modules with similar names.

A registry needs a way to distinguish them.

NextAPI supports scoped modules:

@alice/profile
@bob/profile

This allows independent developers to publish modules without competing for the same global name.

Namespaces are also important inside the application.

A module should not accidentally overwrite another module's routes, backend code, or database resources.

The module architecture therefore provides isolation around module-specific resources.

Conceptually:

@alice/profile
       │
       ├── Routes
       ├── Backend
       └── Database

@bob/profile
       │
       ├── Routes
       ├── Backend
       └── Database

Both modules can exist in the same ecosystem without requiring their internal implementation details to collide.

Versioning

A registry is only useful if developers can depend on modules reliably.

That makes versioning a core part of the system.

A module can specify its version:

profile-page@1.2.0

Applications can then specify compatible version ranges:

profile-page@^1.2.0

A module can also define the versions of NextAPI it supports.

For example:

NextAPI >=1.0.0 <2.0.0

This allows the registry and CLI to reason about compatibility instead of simply installing whatever happens to be available.

Published versions should also be immutable.

If version 1.2.0 changes after an application has already consumed it, reproducibility becomes difficult.

A change should therefore result in a new version.

This gives modules predictable version semantics similar to the package ecosystems developers already understand.

The module lifecycle

From the outside, installing a module is simple.

nextapi add profile-page

Then:

nextapi sync

Internally, there is much more happening.

A simplified view of the lifecycle looks like this:

             nextapi add
                  │
                  ▼
           Stage the module
                  │
                  ▼
        Resolve dependencies
                  │
                  ▼
       Validate compatibility
                  │
                  ▼
             Fetch module
                  │
                  ▼
             nextapi sync
                  │
                  ▼
        Integrate frontend
                  │
                  ▼
         Integrate backend
                  │
                  ▼
        Integrate database
                  │
                  ▼
         Register functions
                  │
                  ▼
        Resolve configuration
                  │
                  ▼
              Application

This is the important architectural difference.

The CLI is not merely copying files.

It is interpreting the module definition and using it to modify the application in a predictable way.

Drift detection

Once modules become part of an application, another problem appears.

What happens if a developer manually changes something that originally came from a module?

This creates what can be thought of as application drift.

The module system therefore needs to know what it installed and what the current state of the application looks like.

That makes synchronization more than an installation command.

It becomes a mechanism for maintaining the relationship between:

Registry
   │
   ▼
Module definition
   │
   ▼
Installed application

If the application changes outside the expected module structure, the system can identify that state rather than blindly overwriting it.

This is important if modules are going to become a long-term part of application development rather than a one-time code generator.

Building and publishing your own modules

The registry is not limited to modules created by the NextAPI team.

The entire point of the registry is to give developers a way to build their own full-stack capabilities and distribute them.

If you build a module for an internal business system, you can keep it private.

If you build something that could be useful to other developers, you can publish it publicly.

This gives the registry two important use cases:

                    NextAPI Registry
                           │
              ┌────────────┴────────────┐
              │                         │
           Public                    Private
              │                         │
       Community modules          Internal modules
              │                         │
       Wider distribution         Controlled distribution

Building your own module

A module does not have to be created by NextAPI itself.

A developer can create a module using the NextAPI module structure and define the parts of the application it provides.

For example, imagine building a task management module.

task-manager/
├── module.json
├── frontend/
│   ├── pages/
│   ├── components/
│   └── ...
├── backend/
│   ├── router.py
│   ├── services/
│   └── ...
└── ...

The manifest describes how those pieces integrate with NextAPI.

The module might expose:

Frontend
    └── /tasks

Backend
    ├── GET /tasks
    ├── POST /tasks
    ├── PUT /tasks/{id}
    └── DELETE /tasks/{id}

Database
    └── tasks

Functions
    ├── create_task
    ├── update_task
    └── assign_task

Once the module is complete, it can be published to the registry.

This is where the registry becomes more than a collection of official features.

It becomes a platform for developers to distribute their own application capabilities.

Public modules

A public module can become part of the wider NextAPI ecosystem.

For example, a developer might build:

@developer/stripe-billing
@developer/ai-chat
@developer/analytics
@developer/notifications

Other developers can discover those modules and install them into their own applications.

The module author does not need to maintain a separate integration process for every application.

The module itself contains the integration definition.

The registry handles distribution.

That creates a feedback loop:

Developer
    │
    ▼
Build module
    │
    ▼
Publish
    │
    ▼
Community discovers module
    │
    ▼
Developers install it
    │
    ▼
More applications use it
    │
    ▼
Module evolves

This is the beginning of an ecosystem rather than simply a framework feature.

Private modules

Not every module should be public.

Companies often build functionality specifically for their own products and internal systems.

A business might have a module for:

Internal CRM
Employee management
Company reporting
Internal billing
Warehouse management
Customer workflows

Those modules may contain proprietary business logic and should not be available to the public.

The same module architecture can therefore be used for private application capabilities.

Company
   │
   ├── Core application
   │
   ├── Private CRM module
   ├── Private billing module
   └── Private analytics module

This gives organizations a way to build their own internal module ecosystem without exposing proprietary functionality.

Sharing modules

A module can also be shared deliberately rather than simply being published as a public community package.

This creates another useful model for teams.

Imagine a company with several applications:

Company
│
├── Customer Portal
├── Admin Platform
├── Mobile Application
└── Internal Dashboard

Instead of implementing the same feature independently in each application, the company can maintain a shared module.

                    Shared Module
                         │
          ┌──────────────┼──────────────┐
          │              │              │
     Customer Portal   Admin App    Mobile App

When the shared module evolves, applications can consume compatible versions of it.

This is one of the reasons versioning and dependency management are fundamental parts of the registry.

The community becomes the extension layer

The most interesting possibility is what happens when module creation is opened to the community.

The NextAPI team does not need to build every possible application capability.

Developers can build modules for the problems they understand best.

One developer might build an invoicing system.

Another might build an AI agent framework.

Another might build a booking system.

Another might build a dashboard.

Another might build an ecommerce feature.

Another might build an internal enterprise workflow.

Each becomes a potential module in the ecosystem.

The registry then becomes a place where developers can discover capabilities rather than simply searching for libraries.

                NextAPI Registry
                       │
       ┌───────────────┼───────────────┐
       │               │               │
    Billing          AI Chat        Analytics
       │               │               │
     Teams          CRM           Notifications
       │               │               │
       └───────────────┼───────────────┘
                       │
                 Your Application

The goal is not to dictate what developers build.

It is to give them a standard way to package and distribute what they build.

The registry as an ecosystem

Package registries gave developers a marketplace for reusable code.

Component registries gave developers a marketplace for reusable UI.

A full-stack module registry can provide a marketplace for reusable application capabilities.

The difference is the level of abstraction.

Instead of searching for:

"React calendar component"

a developer could eventually search for:

"Booking system"

and find a module that provides:

Booking Module
├── Calendar UI
├── Booking pages
├── Booking API
├── Database
├── Availability logic
├── Authentication
└── Functions

The developer is no longer looking for the individual pieces required to build the feature.

They are looking for the capability itself.

NextAPI Core and the Registry

The registry is only one part of the architecture.

NextAPI Core provides the application foundation that modules integrate with.

The core provides the runtime and common infrastructure required by the application, including the Next.js frontend, FastAPI backend, authentication, authorization, database support, Docker configuration, and mobile application support.

The registry provides the extensibility layer.

                         Registry
                            │
            ┌───────────────┼───────────────┐
            │               │               │
         Profile          AI Chat        Analytics
          Module           Module          Module
            │               │               │
            └───────────────┼───────────────┘
                            │
                      NextAPI Core
                            │
                 ┌──────────┴──────────┐
                 │                     │
              Next.js              FastAPI
                 │                     │
                 └──────────┬──────────┘
                            │
                         Database

This separation is intentional.

The core should provide the foundation.

The ecosystem should provide the features.

If every feature had to be included directly inside the core, the core would eventually become a massive collection of unrelated functionality.

The registry allows the platform to remain focused while the ecosystem grows independently.

From components to capabilities

This is the larger idea behind the project.

Frontend development has spent years moving toward composability.

We moved from writing everything manually to reusable functions.

Then libraries.

Then components.

Then design systems.

The same principle can be applied to full-stack application features.

Consider a profile component:

<ProfileCard />

That is reusable UI.

A profile module can instead provide:

Profile Module
│
├── Profile page
├── Frontend components
├── Backend API
├── Database storage
├── Authentication
├── Navigation
└── Functions

The component is a building block.

The module is a capability.

That is a much larger unit of reuse.

Building an application from modules

Once the module becomes the unit of reuse, the application development workflow changes.

Instead of starting with a large empty repository and manually assembling every subsystem, an application can start with the NextAPI foundation and add capabilities as required.

For example:

NextAPI Core
      │
      ├── Authentication
      │
      ├── Teams
      │
      ├── Billing
      │
      ├── AI Agent
      │
      ├── Analytics
      │
      ├── Notifications
      │
      └── Custom Modules

The resulting application is still a normal full-stack application.

The difference is how its capabilities are assembled.

A developer can choose the capabilities required by the product instead of beginning with every feature already bundled into the application.

This also means that two applications can share the same core while having completely different capabilities.

                 NextAPI Core
                      │
          ┌───────────┴───────────┐
          │                       │
       App A                    App B
          │                       │
     ┌────┼────┐             ┌────┼────┐
     │    │    │             │    │    │
   Auth  CRM  AI           Auth Billing Chat

The core remains consistent.

The application becomes composable.

AI as a consumer of the registry

AI is another interesting consequence of this architecture, although it is not the reason for the registry.

AI coding agents are becoming increasingly capable of modifying applications.

But asking an agent to integrate a complex feature still means asking it to understand a large amount of application-specific code.

A structured module registry provides another possibility.

Instead of asking an agent to build every subsystem from scratch, the agent could eventually reason about available modules and their capabilities.

A request such as:

Add authentication, team management, billing, and an AI chat system.

could become a problem of finding compatible capabilities in the registry.

The module manifest provides structured information about:

Capabilities
Dependencies
Compatibility
Frontend
Backend
Database
Functions
Configuration

That gives software agents a much more structured surface to work with than an arbitrary collection of repositories.

AI therefore becomes one potential consumer of the registry.

The registry itself remains useful without AI.

The application as a dependency graph

There is another way to think about this architecture.

A traditional application is often represented as a collection of source files:

Application
├── frontend
├── backend
├── database
├── components
├── services
└── configuration

A module-based application can additionally be viewed as a dependency graph:

                    Application
                         │
              ┌──────────┼──────────┐
              │          │          │
           Profile      Billing     AI
              │          │          │
              │          │          ├── AI Provider
              │          │          │
              └────┬─────┘          │
                   │                │
              Authentication ───────┘

Each module becomes a node in that graph.

Each dependency becomes an edge.

Each function requirement becomes a capability relationship.

This gives the application a structure that can be reasoned about programmatically.

The registry is therefore not simply a website containing downloadable modules.

It is the source of a dependency ecosystem for full-stack applications.

Why the registry matters

The registry is what makes the module model scalable.

Without a registry, modules would simply become another form of local code organization.

With a registry, modules can become distributed software.

They can have:

Authors
Namespaces
Versions
Dependencies
Compatibility requirements
Publishing workflows
Discovery
Installation
Updates
Public or private distribution

That creates the possibility of an ecosystem rather than just a framework feature.

The long-term idea is straightforward:

Build a capability once, package the complete integration, publish it, and make it available to other applications.

Where NextAPI is going

NextAPI started from a relatively simple question:

How can we make building full-stack applications easier?

The answer turned out to be less about adding more features to a starter project and more about changing the unit at which applications are assembled.

Instead of treating the application as a collection of manually connected pieces, NextAPI treats it as a platform that can be extended through modules.

Those modules can contain frontend code.

They can contain backend code.

They can define database requirements.

They can provide and consume functions.

They can depend on other modules.

They can declare their environment requirements.

They can be versioned and distributed through a registry.

That is what makes the idea different from another component library or another full-stack boilerplate.

The objective is to make application capabilities composable.

The NextAPI Core repository is available on GitHub, and the module registry and documentation are available at nextapi.app.

The interesting part is not any single module.

It is what happens when developers can build, publish, discover, share, and install thousands of them.

That is the direction I am exploring with NextAPI.