Cessation of public development of Kefir C compiler

Scope and development resources

From the very beginning, I have worked on the project purely out
of interest for compiling, and the C programming language
provided a rich environment in this respect. Any other
motivations were secondary at best, and were retrofitted
post-hoc. Consequently, publication of the source code has
always been just a side effect of having it. I simply had no
better thing to do with it in the first place. I have worked on
the project in my spare time and on my own budget.

However, by this point, the compiler has outgrown my capacity to
sustain that development reasonably across all important
dimensions: each change needs to take into account correctness
across the whole test suite, integration with other features,
optimization pipeline and performance considerations, compiler
efficiency, other concerns (e.g. debug information management).
A substantial chunk of development time goes into planning the
changes and debugging fallout, significantly slowing down
interesting experiments. Maintaining a reasonable pace of
development would require me to either drop the quality bar and
give up on some of the aforementioned considerations, or to
invest even more time and development resources. I am not
willing to do the former, and I am not able to do the latter
healthily while meeting my primary obligations elsewhere.

Plainly stating, I am not able to preserve current status quo
while keeping this fun for myself. Moving the project into
private mode lets me mentally reframe it as a purely fun
endeavour without any further serious considerations.

Rational calculations

Raison d’etre for this project’s existence has always been
deeply subjective and irrational, in the first place.
Nevertheless, I was also doing some accounting for this sink of
time, especially, lately when scope and development resource
mismatch became more acute. Frankly, even for a project that has
never had ambitions for tangible success, the “return on
investment” has been abysmal. At this point, I concluded
that I need to take this into consideration seriously.

In particular, by “ROI” I mean a much wider range of
things, including (and actually, primarily focusing on)
non-monetary aspects. Seeing real feedback, interactions,
positive engagement is always encouraging and motivating. I am
deeply thankful to everybody who took the time to explore
the project, use it, report bugs, package it, or engage with it
in any other way. However, the current level of activity I am
observing in this regard, rationally, does not allow me to move
my work from a fun hobby into some kind of altruistic pro bono
community service. This current state of affairs is perfectly
reasonable and expected, I do not delude myself about importance
or impact of this work, but this is also important in my
“ROI” calculus.

In the last few months, I have attempted to make some
arrangements that would legitimize this work, and enable me to
work on the compiler in a beneficial manner (again, beneficial in
broader, not necessarily financial sense). Unfortunately, my
attempts were futile and did not bring any results.

Since last autumn, I have also tried to engage in slightly more
publicity regarding this work, including recording a
talk, writing some announcements. The degree of public
presence was limited deliberately by my own view of the project
(un-)importance, my dignity and priorities. Sadly, this
experience hasn’t been neutral and I have suffered some
unpleasant interactions resulting from this.

Greater shifts in software development

Recently, software development as a discipline has changed
significantly with advancements in artificial intelligence. This
project in particular has been unconcerned with new coding
practices so far, primarily, because I derive pleasure from
hand-written implementations of my ideas, and believe that
overcoming challenges the hard way is the main value I get from
it.

Yet, this shift made me re-evaluate the open source code
publishing. Prior to that, I have been positive about free and
open software, and considered this to be the default mode for
work such as kefir. I did not require any justifications from
myself to publish something. Now, however, I feel more and more
that the main beneficiaries of my unpaid work are companies
scraping the internet to train large language models. Currently
accepted status quo in this area goes against my own intentions
in licensing this work under GNU GPLv3. Publication has ceased
to be the “null hypothesis” for me, and requires
explicit mental justification which I am not able to provide.

Why did you write all of this?

I needed to have my thoughts in order about this decision,
and writing them down in publishable format is the best way
to achieve this. I do not expect anyone to care in
particular, this is written for me first and foremost.

You should collect donations/market the project/be more public/etc!

The project already takes significant chunk of time. By
engaging into such activities, I would need to give up any
remaining development time doing activities I don’t like for
unclear prospects. This is too demanding, and most probably
wouldn’t provide stable path forward anyway.

Furthermore, in my view the project does not
warrant being so noisy and clingy about it. I have
certain dignity to preserve.

You should use AI and get X times more productive!

As mentioned, most of development time is actually spent
thinking about solutions, their integration into the current
code base, implications, architecture and design. And then
debugging the fallout. Portion of time spent actually
writing code is relatively small most of the time. In this
project, I do use AI for high level conceptual design
discussions, but enjoy writing the final code myself.
Besides, larger boost to my productivity would be spending
comparable (to typical agentic AI subscription) amount of
money on improving CI infrastructure, as validating changes
in real time is overall the most severe bottleneck I face.

The project is missing Y to get successful!

Indeed, many technical things are still missing. Constraint
is time and resources I can spend on design, validation and
debugging. Churning half-working implementations is
possible, but not feasible (this also applies to the above
note on AI use).

The project is over-engineered, you are yourself to blame!

Over-engineering concern was stated by myself too. However,
this over-engineering is actually an architecture that did
not come to fruition due to development resource
constraints. Below, I will quote an excerpt of an email I
sent sometime in April 2026. This is a very brief
explanation of my vision, which would probably have
warranted more elaboration in other circumstances.

Not necessarily. Overengineering is not an absolute
judgement, but rather judgement with relation to current
capability.

If I take capability of kefir as it is, yes, it is
overengineered. However, the only reason I take “capability
as it is” is that I have arrived at a point where developing
the capability further within current architecture costs me
more than I could justify. The current architecture enables
development in many different directions, but imposes
certain significant costs in doing so. If I had funding and
could work on it full time, the current architecture would
be totally appropriate. As an example, I will take the IR
module. It was envisioned and implemented as completely
platform independent stack machine abstraction isolating the
compiler frontend, and it works like this — it provides
full bytecode set, type language, data layout language,
inline assembly integration, plus a set of APIs to access
platform specific information based on that. In principle,
it could have been advanced as a totally independent, stable
bytecode format similar to JVM bytecode or webassembly. And
I could have developed an interpreter and multiple backend
compilers similar to HotSpot architecture. However, I cannot
afford such detours, so I had just taken the most
straightforward route on putting a C frontend on top of it
and optimizing compiler backend below it. Similarly, the
optimizing compiler itself was structured in a very
particular way: stack IR -> optimizer IR -> target specific
virtual 3AC -> target specific IR -> physical 3AC -> code
emission into the assembly. Of course, now it seems
redundant but it is not necessarily, if one considers
greater vision. Optimizer IR is platform independent by and
large, so it could be progressively applied and then either
interpreted again, serialised into bytecode, or lowered down
into the virtual 3AC cheaply (e.g. without selection DAG and
such features). Virtual 3AC is itself not accidental design.
In certain less optimized modes, it can be devirtualized
right away into physical form with little extra costs.
Secondly, it again could provide a separate input
language/interface similar to AsmJit, so one could just
generate virtual x86-64 code from their application and let
the backend handle some optimizations for it and emit it in
different ways. One could even try to interpret or JIT
compile virtual 3AC, e.g. for certain dynamic analysis a la
valgrind. Target IR itself was designed as the final
component of optimizing chain to provide faithful
representation of machine resources in SSA form, I believe
more faithful than MachineIR of LLVM, and it enables me to
avoid instruction selection complexities (like SelectionDAG)
by offloading these into Target IR passes. Finally, physical
3AC itself is not accidental. Right now, it is only used to
generate different assembly syntaxes, but nothing stops
direct generation of executable code from it, e.g. for JIT
purposes or just bypassing the assembler. One could in
principle build an assembler tool on top of it.

So, you see, the whole pipeline was designed as
pluggable framework with many potential use cases across the
whole stack. My overengineering grievance is not that I
could have achieved current state with less, but that I
cannot achieve my greater vision while keeping it healthy
and reasonable.