Happy 4th birthday, BlenderBIM Add-on! (by the numbers)
Four years ago on this day, the 29th of August 2019, the first commit was made which would later evolve into the BlenderBIM Add-on.
I'd like to reflect on some of the milestones and statistics we've started to collect, and speculate on where we're headed. But before we begin, I'd like to emphasize the goal of the BlenderBIM Add-on project:
The objective of the BlenderBIM Add-on project is to provide a complete free OpenBIM software workflow using for our built environment. Everybody should have the ability to work from early feasibility and concept phase, project coordination, detailed design, fabrication & construction, facility management and building maintenance, post-occupancy evaluation, and tear-down.
In addition to providing features equivalent to existing proprietary software, the new tools will be different in two ways. First, they will be highly modular, allowing users to mix and match to create their own pipelines tailored to their needs, and easily modify or extend the pipeline if it does not suit their needs. The user should have full control over their tools. Secondly, the tools will uphold the highest standards possible of open data standards, exchange, and interoperability conventions, allowing us to integrate data across disciplines to make wiser decisions in the design and management of the built environment.
The BlenderBIM Add-on started when a small commercial building project was designed in Blender. We were then faced with the task of remodeling it in Autodesk Revit. We figured it would be easier to build an entire BIM application and construction documentation tool from scratch rather than face the pain of remodeling it in Revit. It turned out that it was :)
The first 83 lines of code were committed that exported a single site, building, story, and converted objects into faceted brep proxies. The Suzanne monkey was the very first IFC export.
These naive 83 lines of code have grown from being used to visualise compactor machine data when building highways, train station facility management in Australia, to the Hinkley Point C nuclear power plant in the UK. From being used in acupuncturial points within project workflows, we've now taken baby steps into end-to-end project delivery for small scale projects. There have also be numerous presentations at industry events, talks, magazines, podcasts, etc, such as FOSDEM, BILT, CAAD Futures, AEC Magazine, PyCon, and the Boao ISTIF Forum. There have also been multiple academic presentations and academic papers published.
You can read are more detailed history of milestones in the OSArch Wiki.
I believe since early 2023, we are entering a phase where we transition from an alpha to beta, where people can begin to deliver end-to-end small projects with only free software. The major milestone that starts this transition is Andrej joining the team as the first fully sponsored developer. Beta is not just about features and stability, it's also about documentation, training, brand, and financial stability. Thanks to your community contributions, this is the first time we have had enough funding to fully sponsor a developer. This ensures that we can keep up the pace that the community needs.
We've started haphazardly measuring statistics since the beginning of this year, so let's see what that means. Note that statistics for 2023 are naturally incomplete.
IfcOpenShell began in 2011 mostly as a lone wolf effort by Thomas Krijnen. Since then, commits have jumped significantly. I'd say Python is a bit more of a commit heavy language, but also helps lower the bar to new contributors.
We are now at 53 annual contributors. Of which 18 have made more than 10 annual commits.
Reflecting the number of contributors is the number of issues reported. We're closing in on 1,000 new issues every year, which is a lot to keep on top of for a growing project.
Despite this issue growth, we've managed to address the vast majority of them, with an 85% chance that your issue will be resolved sooner or later.
This graph of active (unclosed) issues over time show the turbulent ridges and valleys as we attempt to address issues whilst still building features not on the issues list.
Popularity wise, Github stars have seen a gradual and slowly accelerating increase.
As of this year, we seem to be clocking in roughly about 50,000 downloads per year.
In terms of financials, since the OpenCollective began, we've grown from humbly accepting generous donations and merely covering hardware costs to now at the incredible and scary stage where our expenses exceed our income where we are investing heavily into as much development as possible. Note that these exclude any specific grant funding (e.g. Epic Megagrants, Google Summer of Code stipends, Cesium Ecosystem Grants) or shadow funding and only represent our OpenCollective funding.
All this would not be possible without Thomas Krjinen starting the journey back in 2011, the hundreds of developers (over 150!) that have contributed since then, and hundreds (currently 116) of financial sponsors who have helped it grow, and hopefully will continue to help it grow sustainably to tackle the mammoth ambitions of the project.
Here's to another successful year!
P.S. as a little bonus whilst I was doing these statistics I did a bit of research on other projects. Here are some ballpark figures I gathered from various sources and other project contributors. Emphasis on "ballpark" - as you know this stuff is really hard to measure and there's a lot of "shadow funding" and "double counting" or "bot / automated activity" etc which is difficult to address so empty out your salt shakers please. Just for fun :)
and 20 others.
Comments
The BlenderBIM Add-on has passed through its childhood, when we talked about its potential rather than its capabilities at that time. The BlenderBIM Add-on is now in its adolescence, when its character is becoming apparent. The BlenderBIM Add-on has started a growth spurt towards maturity.
What do I mean by growth spurt? The number of new features and fixes over the past two months will be a new record! Previous two-month totals were 418, 534, 413, and 201. Prior to this, there were about 200+ new features and fixes every two months.
If we estimate that one human year as being equivalent to four BlenderBIM Add-on years, then the BlenderBIM Add-on is now 16 years old and by 29 August 2024, it will be 20 years old. For many people, including myself, the years between 16 and 20 were challenging times. I suspect that the next 12 months will be challenging for the BlenderBIM Add-on.
Funding is important, but as long as the BlenderBIM Add-on continues to deliver new value to more people, I believe that funding will increase, maybe even corporate funding will happen.
I foresee that the biggest challenge that the BlenderBIM Add-on will face is a shortage of diverse domain experts. There is a saying in Africa, “It takes a village to raise a child”. Similarly, it will take the BlenderBIM Add-on community to bring the BlenderBIM Add-on to maturity.
Take architectural drawings as an example; it is maturing very well. @theoryshaw battle-tests the feature on many small commercial projects to report bugs and suggest enhancements. @Moult and @Andrej730 write the code. @Ace creates amazing user tutorials. @theoryshaw and @Ace have domain expertise in architecture, but neither of them are coders.
Now let’s take costing and scheduling as another example. @SigmaDimensions battle-tests the feature, finds bugs, thinks of enhancements, writes the code, and creates amazing user tutorials… all by himself. This is not the ideal model. Ideally, costing or scheduling professionals, even if they are not coders, would be working with @SigmaDimensions. If you are a costing or scheduling professional, I am sure that your help would be welcome!
So how can you help if you are not a coder but have domain expertise in an area that is not yet being developed (nobody is currently doing coding)?
As an example, imagine that you have expertise in vertical transportation. First, check with @Moult to confirm that nobody else is working in this area. Then, write a detailed specification describing how a simple escalator system could be added into the BlenderBIM Add-on. Describe the workflow, menus/buttons, options, etc. involved and show what the final drawings should look like. Pass this specification to @Moult. If it is a simple, clear specification that is relatively easy to implement, I am sure that it will get done. You can battle-test the feature, and when it is ready, create a user tutorial. Then you move on to writing a specification for a slightly more complex system (a simple lift?) that is within your area of domain expertise and repeat the process. Ideally, the slightly more complex system builds on the features of the initial simple system.
I used vertical transportation as an example, but the same general approach can be used for almost any feature that needs to be added to the BlenderBIM Add-on.
You may ask, “Won’t @Moult become the bottleneck in the process?” Programmers can perform miracles if you:
1) Give them a very clear specification (ideally simple, building up into more complex modules)
2) Make yourself available for clarifications
3) Don’t set an unreasonable deadline (ideally, no explicit deadline)
@Moult will share the workload with @Andrej730 . When funding allows, an additional part-time programmer can be brought on board.
@Moult , what do you think? Do you agree that a shortage of diverse domain experts will be the biggest challenge facing the BlenderBIM Add-on over the next year?
There are so many other people who are contributing to the growth of the BlenderBIM Add-on that I did not mention. I did not mean to undervalue their contribution by not mentioning them by name. The main message that I would like to convey to any domain experts reading this is, “Don’t just be a lurker :)”
@Moult , you mentioned that the goal for the next year is to start to transition from alpha to beta software.
I would define three levels of software maturity:
• Production software: The software has been successfully used on large projects and user documentation/tutorials are in place. Production software is meant for general users. I would suggest that IFCcsv and some of the other audit & analyse features are close to production software.
• Beta software: The software has been successfully used on many small projects. “Early-adopter” users will use beta software because user documentation/tutorials are incomplete. I would suggest that the model creation and drawing features of the BlenderBIM add-on are beta software.
• Alpha software: The basic feature building blocks are under development. People who work with alpha software are “bleeding-edge” users who want to steer how features will work and don’t mind interacting with developers. Much of the BlenderBIM add-on software is at the alpha level.
@Moult , how do you feel about this definition?
Happy birthday.
Ad maiora.
In my opinion the revolution of these
are like the satoshi nakamoto's first email
WHoop WHoop!
@Lurker the biggest challenge is probably development being able to keep up with demand. I think there are a lot of professionals across many disciplines eager to try (and then provide feedback) and given that we're still in the "catching up to feature parity with proprietary software" phase there's a ton of already solved problems (both UX and functionality wise) that we just need more time and code written to address. For example structural / energy modeling is stalling simply because we're stretched thin, not due to a lack of interested testers. Whereas 4D / 5D has progressed because code is being written (by a professional in that discipline too, which is awesome).
I am also worried about optimisation in certain things like drawings and large model operations.
Im confident we who have certain needs are more than forgiving. To be a living open source comunity, the development is stunning. Also, for us who are end users of BB, if i knew coding i would have been more than happy to participate, i assume the feeling is mutual for many of us.
Keep up the fantastic work Moult.