FieldCraft is MIT. PayKit is MIT. The adapters, the templates, the core packages — all MIT. Do whatever you want with them.
I did not agonise over this decision. Open source is my default, and I want to explain why.
It forces me to write better code
When anyone can read your source, you write differently. You think about naming. You write comments where the logic is not obvious. You structure things so a stranger can navigate the codebase without a tour.
Private code rots. You leave TODOs that never get done. You hardcode values because "only I will see this." You skip documentation because "I know how it works." Open code does not let you get away with that — or at least, you feel the weight of it when you do.
I write better code when I know it is public. That alone is worth it.
Trust is visible
If someone is evaluating my tools, they can read every line. Not a demo, not a marketing page — the actual implementation. They can check how I handle edge cases, whether I write tests, how I structure my packages.
That is a stronger pitch than any landing page. The code is the resume.
Issues and PRs are free labour
I do not have a QA team. I do not have beta testers on payroll. But people who use my packages in production find bugs I never would have caught. They open issues with reproduction steps. Sometimes they submit fixes.
Every issue is a test case I did not have to write. Every PR is a contribution I did not have to make. The economics of open source are unreasonably good for a solo developer shipping tools.
What stays paid
I draw the line at tooling that adds convenience, not capability. The open-source packages handle rendering, validation, payments — the core functionality. The commercial add-ons (FieldCraft Pro's form builder, theme editor, response viewer) are visual tools built on top of that core.
You can build everything Pro does with the MIT packages and enough time. Pro saves you the time. That is what you are paying for.
If my commercial tools disappeared tomorrow, your forms would still render, your payments would still process. No lock-in.
The uncomfortable part
People will use your code in production, make money from it, and never contribute back. That is the deal. If that bothers you, do not open-source your work.
It does not bother me. Every silent install is someone who found my code useful enough to depend on. I would rather have a thousand quiet users than ten who send thank-you emails.
Why MIT specifically
I looked at Apache 2.0, LGPL, and various "fair source" licenses. MIT won because it is the simplest. One paragraph. No patent clauses to explain. No attribution requirements beyond keeping the license file.
The simpler the license, the more people will use it. Developers skip packages with licenses they do not immediately understand. MIT is understood by everyone.
I want people to use my tools. The license should make that easy, not add friction.