Last month we put the first packages of the Datafication SDK on NuGet. Later this week we publish something different: our first open-source product, a notebook platform for .NET called Verso.
Before it goes out, I want the rules it was built under written down somewhere public. There are four, and none of them is original. What matters is that I treat them as constraints instead of aspirations, and that I am willing to pay what each one costs.
1. Native to the platform
No Node.js sidecars, no Python bridges, no bundled driver binaries. A tool built for .NET installs with dotnet add package, runs inside your process, debugs with your debugger, and deploys with your application.
This rule is expensive up front. Wrapping a tool from another ecosystem is almost always faster than building the thing natively, and in a demo the wrapper looks about the same. It stops looking the same in CI, where a second toolchain has to be installed and version-matched, and in production, where a process boundary sits between your code and the thing it is trying to drive. I would rather do the slow thing once.
For the SDK that meant a core library with no external dependencies. For the notebook it means the execution engine is an ordinary .NET library you can reference from your own application, not a separate kernel process you talk to over a socket.
2. Extensible to the core
Every built-in feature is built on the same public interfaces anybody else gets. There are no private APIs held back for our own code.
The test is easy to state and hard to pass: could somebody outside the company have built this feature with the packages we publish? If the answer is no, the extension surface is not finished, and the fix is to finish the surface rather than to give ourselves a back door.
In the notebook this goes all the way down. The language kernels are extensions. The renderers are extensions. The notebook surface itself is a layout, and layouts are extensions too, which means what you see when you open a file can be replaced with something that is not a notebook at all. I will show what that makes possible over the coming months.
If the extension surface is not good enough for our own features, it is not good enough to ship.
3. Open where it is open
What we open-source is MIT licensed and developed in public. The repositories, the issues, the release notes, and the documentation are the same ones we work from every day. The license will not change under you. Contributions come in under a Developer Certificate of Origin, mine included.
The Datafication SDK is a commercial product, and it says so up front. It is free for small teams and open-source projects, and licensed for larger organizations. That income is what pays for the open-source work, and you deserve to know that rather than guess at it. Blurring the line between the open thing and the paid one is how projects end up changing their license a couple of years later, and I do not intend to be one of those.
4. We use what we ship
Every product started as something I needed. The SDK came out of building data products for other people and hitting the same gaps every time. The notebook came out of wanting somewhere to look at what the SDK produced without leaving .NET. We use both every day, which is still the quickest way to find out what is wrong with them.
Documentation gets written next to the code instead of after it. The guides on the product site are generated from the same markdown that lives in the repository, so the docs and the code ship together and any drift shows up in the diff.
What the rules cost
They make us slower. Building something natively takes longer than wrapping what already exists. A public extension surface takes longer than a private hook. Writing the guide alongside the feature takes longer than writing it later, if it gets written later at all.
I pay it because the other kind of product is the one that works in the demo and lets you down in the build pipeline. And because a small company's real advantage is that it can afford to be stubborn about the things a larger one has to trade away.
If we break one of these, tell me. The address is support@datafication.co, and the public repositories take issues. This blog will keep recording the reasoning behind each release, not just the result.