Forem: André Ahlert

Soda Moved to ELv2. Provero Is Apache 2.0.

André Ahlert — Wed, 01 Apr 2026 14:19:06 +0000

When Soda changed its license from Apache 2.0 to Elastic License v2, teams that relied on Soda Core as open source infrastructure had to re-evaluate. This post explains what changed, what it means for you, and what alternatives exist.

What happened

Soda Core was originally released under Apache License 2.0. In 2023, Soda switched to the Elastic License v2 (ELv2). The change applied to all new versions of Soda Core and its associated packages.

ELv2 is not an open source license by the OSI definition. It adds two restrictions that Apache 2.0 does not have: you cannot offer the software as a managed service, and you cannot modify the license key functionality. For internal use at most companies, ELv2 is permissive enough. But for platform vendors, consultancies embedding Soda in their products, or organizations with strict open source policies, it creates friction.

Who is affected

Internal data teams (Low impact) -- ELv2 allows internal use. You can keep using Soda Core if the license terms work for your legal team.

Data platform vendors (High impact) -- If you embed data quality checks in a product you sell, ELv2 prohibits offering it as a managed service without a commercial agreement.

Consultancies and integrators (Medium impact) -- Depends on how you distribute. If you ship Soda as part of a client deployment, review the license terms with legal.

Open source projects (High impact) -- ELv2 is not OSI-approved. If your project requires OSI-approved dependencies, you cannot depend on Soda Core.

This is a pattern, not an exception

Soda is not the first data tool to make this move. The playbook is familiar across the industry: release as open source, build adoption, then change the license to protect a commercial offering. Elastic did it. MongoDB did it. HashiCorp did it. Each time, the community had to decide whether to accept the new terms, fork the project, or find an alternative.

The pattern is rational from a business perspective. But it breaks trust with teams who built infrastructure on the assumption that the license would not change.

What Provero does differently

Provero is licensed under Apache 2.0. Every feature ships in the open source package: anomaly detection, data contracts, all 16 check types, the CLI, the Airflow provider. There is no cloud-only tier and no feature gating.

We are pursuing acceptance into the LF AI & Data Foundation, which means the project would be governed by a neutral foundation, not a single company. Foundation governance makes unilateral license changes structurally difficult.

	Provero	Soda Core
License	Apache 2.0	ELv2
OSI approved	Yes	No
Managed service allowed	Yes	No
Anomaly detection	Included	Cloud only
Data contracts	Included	Partial (Cloud for full)
Governance	Targeting LF AI Foundation	Soda Inc.
Check format	YAML	SodaCL
Migration path	`provero import soda`	N/A

Migrating from Soda

If you have existing SodaCL checks, Provero includes a converter that maps Soda check syntax to Provero YAML:

pip install provero
provero import soda checks.yaml -o provero.yaml
provero run

SodaCL	Provero
`missing_count(col) = 0`	`not_null: col`
`duplicate_count(col) = 0`	`unique: col`
`row_count > 0`	`row_count: { min: 1 }`
`freshness(col) < 24h`	`freshness: { column: col, max_age: 24h }`
`valid_count(col) = ...`	`accepted_values: { column: col, values: [...] }`

Checks that don't have a direct equivalent are preserved as YAML comments, so nothing is silently dropped.

Our position on licensing

We think data quality is infrastructure. It belongs in the same category as linters, test frameworks, and CI tools. You would not accept a linter that moved half its rules behind a paywall. Data quality checks should work the same way: open, portable, composable.

Provero will stay Apache 2.0. Not because we are against commercial models, but because we believe the right way to build a business around open source is to sell services, hosting, and support on top of a fully open core. Not to restrict the core itself.

pip install provero
provero init
provero run

GitHub | PyPI | Docs

I built a backend language that a 3B model writes better than Express

André Ahlert — Wed, 01 Apr 2026 10:40:12 +0000

I've been building web apps for years and the thing that always bothered me is how much ceremony goes into something that should be simple. A task list with auth shouldn't need 15 files across 3 directories with 200 lines of config.

So I built Kilnx, a declarative backend language. 27 keywords, compiles to a single binary, SQL inline, HTML as output. At some point I started wondering: if the language is this small, can a tiny local LLM write it? A model that fits on a phone?

I ran the benchmark. Kilnx won every round.

What Kilnx looks like

A complete app with auth, pagination, htmx, and a SQLite database:

config
  database: "sqlite://app.db"
  port: 8080
  secret: env SECRET_KEY required

model user
  name: text required
  email: email unique
  password: password required

model task
  title: text required
  done: bool default false
  owner: user required
  created: timestamp auto

auth
  table: user
  identity: email
  password: password
  login: /login
  after login: /tasks

page /tasks requires auth
  query tasks: SELECT id, title, done FROM task
               WHERE owner = :current_user.id
               ORDER BY created DESC paginate 20
  html
    {{each tasks}}
    <tr>
      <td>{title}</td>
      <td>{{if done}}Yes{{end}}</td>
      <td>
        <button hx-post="/tasks/{id}/delete"
                hx-target="closest tr"
                hx-swap="outerHTML">Delete</button>
      </td>
    </tr>
    {{end}}

action /tasks/create method POST requires auth
  validate task
  query: INSERT INTO task (title, owner)
         VALUES (:title, :current_user.id)
  redirect /tasks

kilnx build app.kilnx -o myapp gives you a ~15MB binary. Registration, login with bcrypt, sessions, CSRF, validation, pagination, htmx inline delete. No framework, no ORM, no node_modules.

The question

The Kilnx grammar fits in 400 lines of docs. Express, Django, and Node.js each have thousands of pages of documentation, dozens of APIs, and multiple ways to do the same thing.

I wanted to know if that difference in surface area shows up when you ask small LLMs to generate code. Not GPT-4 or Claude, but models you run on a laptop with Ollama. Models between 1B and 7B parameters.

Setup

I wrote 10 equivalent tasks across four stacks (Kilnx, Express, Django, vanilla Node.js):

#	Task	Difficulty
1	Hello World page	trivial
2	User model definition	easy
3	Page with database query	easy
4	Create with validation	medium
5	Auth + protected route	medium
6	Delete with htmx response	medium
7	SSE notifications	medium
8	Chat websocket	hard
9	Stripe webhook	hard
10	Complete mini app	hard

Five models, three families, all local:

Model	Parameters	Disk
Qwen 2.5 7B	7B	4.7 GB
Qwen 2.5 3B	3B	1.9 GB
Qwen 2.5 1.5B	1.5B	986 MB
Phi-4 Mini	3.8B	2.5 GB
Llama 3.2 1B	1B	1.3 GB

Three validation passes on every output:

Keyword matching - does the code contain the structural elements the task requires?
Syntax check - kilnx check (semantic analysis), node --check, python compile
LLM-as-judge - Qwen 7B rating syntax/completeness/correctness/idiom (0-3 each)

Every combination ran 3 times. 600 generations, 600 judge evaluations.

About fairness

This is important. Kilnx has never appeared in any training dataset. Zero .kilnx files exist on the internet outside my repo. Express and Django have millions of code examples baked into every LLM's weights.

I gave the models the Kilnx grammar reference (11.7K chars) as prompt context. Express, Django, and Node got no reference docs because they don't need them.

If anything, this setup gives the established frameworks a huge advantage. They've been pre-trained on the entire Stack Overflow + GitHub history. Kilnx gets one document.

The numbers

Structural correctness (keyword score, averaged over 3 runs)

Model	Kilnx	Express	Node.js	Django
Qwen 2.5 7B	100%	88%	93%	83%
Qwen 2.5 3B	99%	88%	89%	87%
Qwen 2.5 1.5B	99%	85%	87%	74%
Phi-4 Mini	98%	88%	93%	85%
Llama 3.2 1B	90%	78%	77%	77%

Qwen 3B, a 1.9 GB model, scores 99% on Kilnx, a language it has never encountered. The same model gets 87% on Django, a framework it has seen millions of times during training.

When you shrink from 7B down to 1B, Kilnx drops 10 points. Node.js drops 16. The simpler grammar holds up better as the model gets dumber.

Tokens per task (completion only)

Framework	Qwen 7B	Qwen 3B	Qwen 1.5B	Phi-4 Mini
Kilnx	105	112	111	95
Django	195	226	152	199
Express	302	349	265	315
Node.js	347	381	333	490

3x fewer tokens than Express/Node. This is not a style difference. It's the same functionality. A chat websocket in Kilnx is ~110 tokens:

socket /chat/:room requires auth
  on connect
    query: select body, author.name, created from chat_message
           where room = :room
           order by created desc
           limit 50
    send history

  on message
    validate
      body: required max 500
    query: insert into chat_message (body, author, room)
           values (:body, :current_user.id, :room)
    broadcast to :room fragment chat-bubble

The Express version of the same task runs ~420 tokens of socket.io setup, middleware, database calls, and room management.

Session economics

Kilnx has a cost that Express doesn't: the grammar reference takes ~3,100 prompt tokens. But that's loaded once per session. The per-task completion cost is what scales.

Over a real session with Qwen 3B:

Tasks	Kilnx	Express	Node.js
1	3,269	464	501
10	4,277	4,640	5,010
25	5,957	11,600	12,525
50	8,757	23,200	25,050
100	14,357	46,400	50,100

Kilnx becomes cheaper than Express at task 9. By the end of a workday (call it 50-100 tasks with a copilot), you've used 71% fewer tokens. If you're paying per token on an API, that's real money. If you're running locally, it's real time.

Raw output from the 3B

No editing, no cherry-picking. This is Qwen 2.5 3B (1.9 GB on disk) generating a complete app from scratch, having seen the Kilnx grammar for the first time in the prompt:

config
  database: env DATABASE_URL default "sqlite://app.db"
  port: 8080
  secret: env SECRET_KEY required

model task
  title: text required
  done: bool default false
  owner: user required
  created: timestamp auto

auth
  table: user
  identity: email
  password: password
  login: /login
  after login: /tasks

page /tasks layout main requires auth
  query tasks: select id, title, done from task
               where owner = :current_user.id
               order by created desc
               paginate 20
  html
    <input type="search" name="q" placeholder="Search tasks..."
           hx-get="/tasks" hx-trigger="keyup changed delay:300ms"
           hx-target="#task-list">
    <table id="task-list">
      <tr><th>Title</th><th>Done</th><th></th></tr>
      {{each tasks}}
      <tr>
        <td>{title}</td>
        <td>{{if done}}Yes{{end}}</td>
        <td><button hx-post="/tasks/{id}/delete"
                    hx-target="closest tr"
                    hx-swap="outerHTML">Delete</button></td>
      </tr>
      {{end}}
    </table>

action /tasks/create method POST requires auth
  validate task
  query: insert into task (title, owner)
         values (:title, :current_user.id)
  redirect /tasks

Auth, pagination, htmx search with debounce, inline delete, form validation. It even added the search input on its own, that wasn't in the prompt.

Why I think this happens

Express forces the model to make a lot of decisions. CommonJS or ESM? Which middleware in what order? Prisma or Sequelize or raw queries? Passport or express-session or JWT? EJS or Pug or Handlebars? Each fork is a place where a small model can pick wrong.

Kilnx has one way to do each thing. One keyword for auth, one keyword for pages, one for actions. The model doesn't pick between approaches because there's only one approach. The decision space is so small that even a 1B model mostly gets it right.

I don't think this is unique to Kilnx. Any DSL with a tight, regular grammar would probably show the same pattern. The surface area of a language directly predicts how well small models can generate it. I haven't seen anyone optimize for that yet.

What I'd do with this

If you're an indie dev or a solo founder shipping CRUD apps:

A 3B model running locally gives you 99% accuracy on Kilnx with no API costs, no internet, no privacy concerns. The 7B hits 100%. You don't need to send your code to OpenAI to get a working backend.

If you're using a paid API, the 71% token reduction over a session adds up fast. Especially if you're iterating on features all day.

If you're just curious, the whole language is 27 keywords. You can read the grammar in 10 minutes.

Links

curl -fsSL https://raw.githubusercontent.com/kilnx-org/kilnx/main/install.sh | sh
kilnx run app.kilnx

I built an MCP Server that lets Claude manage your Substack

André Ahlert — Sat, 14 Mar 2026 14:07:52 +0000

The Substack web UI is fine for casual use, but if you're a power user who publishes daily, manages engagement, and wants to automate interactions, you need something faster.

I built @postcli/substack, a tool that gives you three interfaces to Substack:

1. CLI - Direct commands from your terminal

postcli-substack notes publish "Shipping fast from the terminal"
postcli-substack posts list --limit 5
postcli-substack feed --tab for-you

2. TUI - Full interactive terminal UI with 6 tabs

postcli-substack tui

Navigate with j/k or arrow keys, scroll with mouse wheel, open posts in browser with 'o'. It's keyboard-driven and fast.

3. MCP Server - 16 tools for AI agents

{
  "mcpServers": {
    "substack": {
      "command": "postcli-substack",
      "args": ["mcp"]
    }
  }
}

Tell Claude "like back everyone who liked my last note" and it just works.

The automation engine

The part I'm most proud of is the automation engine. It uses SQLite to track processed entities (no duplicate actions) and supports triggers like:

Someone likes your note → auto-like their latest note back
New note from specific authors → auto-like or restack
New post from specific publications → auto-restack

Auth without API keys

Substack doesn't have a public API. Auth works by extracting your existing Chrome session cookies (AES-128-CBC decryption) or manual cookie entry.

postcli-substack auth login

Install

npm install -g @postcli/substack

89 tests. CI on Node 18/20/22. Open source (AGPL-3.0).

GitHub: https://github.com/postcli/substack
NPM: https://www.npmjs.com/package/@postcli/substack