Tending Bonsai

Somewhere in your copy of Bonsai there is a file called FixRevit2025TINs.py.

Nobody planned that file. It wasn’t on a roadmap and no committee approved it. Somebody was handed a survey exported from a 2025 version of Revit, found that the triangulated surfaces in it came through wrong, worked out precisely how they were wrong, and wrote a short Python recipe to put them right. That recipe shipped. It is on your machine now, waiting for the day somebody hands you the same file.

It has neighbours: FixArchiCADToRevitDoorSwings.py, FixArchiCADToRevitSpaces.py, RemoveRevitUniformatClassification.py. There are many more of these recipes, most of them one readable file.

Read the list one way and it is a directory of other people’s export bugs with the vendors named - the evidence for why IFC, the open file format Bonsai keeps building models in, gets blamed for things it didn’t do. Read it the other way and it is a maintenance log for a trade, kept by the people in it.

That is mutual aid, and here it comes with a filename.

Nothing in FixRevit2025TINs.py required generosity. It was simply cheaper to share the fix than for everybody who met that survey to work it out again, and that is how most of what is in your copy of Bonsai got there.

What kind of arrangement this is

Bonsai is Free Software, and the usual account of what that means - you get the source code, it costs nothing - describes the paperwork rather than the arrangement. The arrangement is that the people who use this software are the people who make it, and that they are doing the same work as you.

A commercial tool is built by a company guessing, at a distance, what its customers need. Bonsai is built by people who hit the problem themselves that morning. The guessing step is missing, which is why the fixes are so specific and so oddly named.

Nobody is selling it to you. There is no upgrade to be nudged towards, no edition you are on the wrong side of, and nothing about your model kept slightly awkward to move.

The distance from user to developer

In most software there is a wall. Users are on one side of it and developers on the other, and the only way through is a support ticket that may or may not be read. Here there is a gradient instead, with a good many steps on it:

• Using it, and nothing else. This is where nearly everybody is, and it is a perfectly good place to stand.
• Reporting a problem precisely - a file that reproduces it, the steps, what you expected. This is the step most people underrate; a well-reported bug is often most of a fix.
• Answering somebody else’s question, because you happen to have solved that one last month.
• Writing a script for a tedious job of your own, and posting it when it turns out to work.
• Fixing something small in the add-on itself, or looking after a corner of it because you have ended up knowing that corner better than anybody.

Most people stop somewhere in the middle and stay there for years, which is the normal case rather than a failure to progress. No step is closed to you, and each is a much smaller move than it is elsewhere. You never have to touch a line of Python; plenty of people use Bonsai for years without writing a script.

The tools for it are already installed

The distance between running Bonsai and changing it is shorter now than it has ever been.

The add-on is written in Python, with nothing compiled in it. There is no build step between you and the program - what you are running is what you can read, in the editor you already have. The IFC library underneath is compiled C++, which is a bigger undertaking, but it isn’t where most of Bonsai lives.

Blender ships a text editor and a Python console as standard, so nothing has to be installed before you can start poking at the model in front of you. A script that lists every wall in your project is only a few lines, and the documentation has a worked example.

The drawing output is the same. The symbols, hatch patterns and stylesheets that make your drawings look the way they look are ordinary .svg and .css files in the add-on, and the titleblocks are .svg files you are meant to replace with your own. Changing how your drawings look is editing a stylesheet, not filing a feature request.

Where help comes from

To anybody used to buying software, “free software” reads as “unsupported”, and that is a fair worry. The answer is that help comes from people doing the same work as you, in public, and it is the better arrangement more often than you would expect.

There is a live chat and a community forum at OSArch, where most of the conversation happens. Ask about a wall behaving strangely and there is a fair chance of being answered by somebody who wrote the wall tool, in the same thread, that day. There is no tier, no ticket number, and nobody whose job is to close your case.

Because the conversation is public, your question and its answer stay where the next person will find them. And when the answer turns out to be that the software is wrong, it can go straight to a fix, because the people in the thread are the people who can make one.

If you want to go further than asking, there is a guide for contributors covering bug reports, documentation and code, in roughly that order of usefulness.

Your tools are yours

A carpenter owns their tools. They go with them when they leave, and nobody can take them back. Skill and tool stay together, because the skill lives partly in the tool - in a chisel sharpened a particular way, in a jig made for a job that will come up again.

Software in this industry works the other way round. It is rented, not owned. The subscription belongs to the practice, is priced so that only a practice can hold it, and is withdrawn when you go. What goes with it is not only your ability to work but your ability to open your own past work, the library you spent a decade building up included. Skill accumulated inside a tool you can no longer open is skill held hostage.

Staying put doesn’t make it safe either. Whoever rents you the tool can change the terms, raise the price or discontinue the product, and a rented tool can vanish from under a whole practice as easily as from under one person.

Bonsai is yours in the carpenter’s sense. It works the same whether you are a hundred-person practice or working from a spare room, and if you leave, it comes with you.

That is where this guide’s two answers meet. The work you produce is yours and outlives the software that made it; the means of producing it are yours too. Your model and your tools, both, and neither of them on loan.

Last updated 8 October 2026.