About Bronze Venture

We take inspiration from simple designs that endure. The penteconter was not the most advanced ship available. The trireme was faster, but it also required three banks of oars, a larger crew, a more demanding hull, and a shipwright with the necessary experience. The penteconter remained in service for centuries because it was relatively simple to build, could be operated by a small community, and could be repaired on a beach with materials that were available locally. It was not the best ship in every respect. It was a ship that could be maintained.

Simple does not mean small, and it is not a stage a product passes through before becoming more complete. It is a property that has to be maintained. Every feature adds something that can fail, something that needs to be explained, and something that someone will eventually have to maintain. A durable product is one whose parts remain understandable. We would rather build something you can keep in your head than something that is impressive at first and difficult to understand later.

Durability also requires stability. Most software is not unreliable so much as continually changing. Menus move, familiar workflows are replaced, and products acquire new ways of doing things that users then have to learn. We do not consider that progress by default. Changes have to justify the cost of making users adapt to them, and many changes do not. What you learn about our software should continue to be true.

We are not interested in adding AI simply because a product is expected to have it. If a feature does not address a problem people actually have, or if the benefit is not worth the cost of maintaining it over the life of the product, we do not build it. Sometimes the right answer is to leave a feature out. We do not consider that a missing part of the roadmap; we consider it a decision.

Your data is not used to train our models. We do not train on customer content, and we do not provide that content to others for training. When we host a workspace, there are circumstances in which the service technically gives us access to what is stored there, and we think that distinction should be stated plainly. Access is limited to operating the service, handling a support request you have made, or complying with a legal requirement. Training is not one of them.

We also think there is a real cost to building features for appearances. Every feature has to be explained, supported, maintained, and carried forward long after the reason for adding it may have disappeared. That burden does not become smaller because the feature happens to be built with AI.

We do not think useful software should arrive with conditions attached to where it runs. A great deal of what is sold now works only while the vendor keeps it working — on their machines, at their prices, for as long as they consider it worth their while. That is usually described as convenience, and it is closer to a lease. We publish the source instead. Put it on hardware you own, hold your own data, change whatever does not suit you, and owe us nothing afterwards. Running it yourself is a supported way to use our products, documented and tested as such, rather than a route left open for anyone stubborn enough to work it out unaided.

Publishing the source also means the work is not confined to the people we employ. Anyone who runs an instance, builds against it, submits a patch, or simply wants to verify what the software does can read it, test it, correct it, and take issue with the decisions behind it. Software improves when more people are able to work on it, and we would rather be argued with than left alone. What we are after is not a repository posted and then abandoned: the code has to be documented well enough to follow, structured well enough to maintain, and sturdy enough to keep running without our attention. Whether you pay us to operate it, operate it yourself, or use it as the foundation for something we never imagined, it should still be worth having.

We build with a C-based toolchain. High-level interpreted languages are excellent tools where they are the right fit, but the core of a product has different requirements: it should not depend on a particular operating system, runtime, or ecosystem in order to keep working. Some will read C as a dated choice. We would call it settled ground — it compiles nearly everywhere, it has been in continuous production use for more than fifty years, it was designed for performance, and it is not waiting on anyone's roadmap. Software built this way can move as your infrastructure changes instead of being rewritten to get there.

We design for efficiency and low resource consumption from the start. It is not something we want to retrofit after a product becomes successful. Core software should make reasonable use of the hardware it runs on, with predictable resource requirements and as little unnecessary machinery between the user and the work being done. That does not mean optimizing every line at the expense of development speed. It means choosing technologies and designs that make efficient operation the normal case rather than an ongoing rescue project.

We assume the design has to last far longer than the assumptions behind it. Software routinely outlives the circumstances it was written for. We therefore favour simple systems, conservative dependencies, clear interfaces, and technologies that are likely to remain understandable years from now. Maintainability is not just about making today's code easier to change; it is about making tomorrow's engineer capable of understanding it in the first place. A product should not require archaeology to keep working.