Open source software has shaped how we build software.

It still matters.

We love open source.

At Flyweight Development (FWD), we have released many packages and components as open source, and we plan to keep doing that.

At the same time, because of the nature of some core products, we keep them closed source to run a sustainable business.

For selected larger projects, we are now taking a different path.

We call it OPS.

OPS stands for Open Prompt Software.

What is OPS?

In OSS, you publish the full source code.

In OPS, we publish the full README and the full prompt that can be used to generate the software yourself.

The implementation is not hidden behind mystery.

The construction logic is made explicit.

You get the exact intent, architecture direction, and generation instructions we use.

Then you can build it yourself and shape it for your own needs.

Why we are doing this

The industry changed fast.

Code became cheaper.

Generation became better.

Iteration became the main bottleneck.

For many products today, the long term value is less about one static code snapshot and more about the quality of the prompt, product decisions, and architecture constraints.

A good prompt can produce a strong baseline quickly.

A great prompt plus a solid architecture can produce a product that is maintainable and adaptable.

That is where we want to contribute.

The first OPS release

Our first OPS release is FWD-Hub.

FWD-Hub is a customer support and help channel combined with product release logs.

We needed it for our own products, so we built it.

There will be a separate post focused on FWD-Hub itself.

This post is about the model.

FWD-Hub is the first OPS release.

We will gradually release more OPS components from larger projects, so teams can include the parts they need.

Each OPS release includes a standalone prompt you can use to build the software yourself.

For teams that do not want to self host or customize, we also provide a hosted solution at hub.flyweight.dev.

We keep that priced to stay accessible.

Why not OSS for this project?

We release software very quickly now.

That is good for customers, but it changes how we need to work as a small team.

A serious OSS project carries real maintenance responsibility.

You need to review issues.

You need to review pull requests carefully.

You need to maintain direction and quality over time.

Even with AI tools, you still cannot blindly accept every PR and hope for the best.

Review and maintenance still require attention, context, and ownership.

Across many fast moving repositories, that maintenance overhead becomes very real.

OPS gives users freedom to build and extend on their side, while letting us keep our product focused and aligned with our own needs.

That helps us avoid feature bloat and keep velocity high.

Security and realism

OSS has major security strengths.

More eyes can find bugs faster.

That is real.

There is also another side.

If a public codebase is poorly maintained, attackers can inspect it, track stale dependencies, and target known weak points while fixes lag behind.

For example, when maintainers are overloaded and dependency updates are delayed, known vulnerabilities can stay exposed longer than they should.

OPS does not magically solve security.

Nothing does.

But it is a model that matches our maintenance capacity better for this kind of project.

Not anti OSS, just a better fit for this case

We are not turning our back on open source.

We still believe in OSS.

We still use OSS.

We still publish OSS.

We still contribute to OSS.

OPS is simply the most practical way for FWD to contribute in this specific phase, with a small team and many active products.

It is better than keeping everything closed.

It is more sustainable for how we ship.

It lets builders take the prompt and run with it.

And it keeps us focused on building great software on top of a solid and scalable architecture.