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.