Who makes Bonsai

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

Nobody planned that file. It was not 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 thirty-nine 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 behind The file is the document and its argument about why IFC gets blamed for things IFC did not 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, either. 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. Cooperation of that kind is the ordinary case rather than the rare exception. It goes unremarked because there is no drama in it.

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. The point is not that you should be climbing, but that no step is closed to you and that moving one step is a much smaller thing than it is elsewhere.

So you never have to touch a line of Python, and nothing here is hinting that you will have to. Plenty of people use Bonsai for years without opening the scripting tab. The claim is about what is possible, not about what is expected of you.

The tools for it are already installed

This is the part that has changed most, and it is worth saying plainly: the distance between running Bonsai and changing it is shorter now than it has ever been.

The add-on is four hundred and forty-seven Python files 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 is not where most of Bonsai lives.

Blender ships a text editor and a Python console as standard, in a workspace tab you have probably been ignoring, 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 about four 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.

Two things follow from that conversation being public. Your question and its answer stay where the next person will find them, so the same problem gets solved fewer times. 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 are theirs on somebody else’s site and theirs at home, 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 is not usually like that. The licence 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 projects you drew, the details you refined, the library you spent a decade building up. Skill accumulated inside a tool you can no longer open is skill held hostage.

Bonsai is not like that, and neither is anything you make with it. You can install it on your own machine tonight, and it works the same whether you are a hundred-person practice or working from a spare room. If you leave, it comes with you, and so do your files, because they were never in anybody’s format but the standard’s.

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

Last updated 4 September 2026.