FOSS projects often struggle to build and follow a coherent development roadmap that lets contributors add new features while also improving code quality, removing deprecated features, and generally improving the application. After all, it’s more fun to work on new features than it is to write unit tests, refactor code, and fix bugs.
There’s well over 200 various addons for FreeCAD available just in the official add-on manager. Many more possibly flew under the radar or simply never have been shared with anybody.
For some developers, creating an add-on is a way to test ideas and see if they resonate with a larger audience. For others, it’s the first step towards contributing to FreeCAD itself. The add-on ecosystem is hugely important for the community at large.
One of the hallmark features of FreeCAD is that various parts of its UI have a lot of similar options, which means a lot of cognitive load, especially for beginners. A very popular “offender” here is the geometry constraints toolbar in Sketcher. It has 18 different constraint options, more than most popular commercial CAD offerings like Fusion 360, Onshape, and Creo. That's not a bad thing on its own, but it adds a lot of mileage when you need to dimension an entire complex sketch.
Pull request rot is a quick way to turn off first-time and long-time contributors. The merge meeting is one way to get PRs moving again.
Historically, the duration of FreeCAD development cycles has been uneven, anywhere between a few months and 2+ years.
We already talked about reasons and ways to make releases more predictable in one of the recent posts. But the truth is, this is a much older conversation that has been going on in the community for years now: at FOSDEM, in the forum, and in various other venues and social channels. The hackathon in Vancouver was a perfect opportunity for the developers community to set some boundaries for v1.0.
FreeCAD is commonly criticized for being difficult to get started with.
This criticism, while possibly overstated, is valid.
Besides working on Ondsel, I mostly work on the Path Workbench. Path has a unique user base made up of hobbyists and machinists. These people are using Path to generate G-code for the CNC machines and the code almost always has to be tailored for a specific machine.
Once you’ve edited the G-code once or twice, it’s natural to want to customize your postprocessor and that means editing a little Python code. Occasionally, one step leads to another and the user wants to contribute their changes ‘upstream’ so they can be used by others. It’s a common story and is, in fact, exactly how I got involved in open-source development.
FreeCAD 0.21 has just been released with numerous new features and improvements. Some of the Ondsel team members have been regular contributors to FreeCAD for many years, but this is the first time we participated in a development cycle as a commercial entity. Let’s take this opportunity to step back and reflect on it.
Back in February, we posted an explanation of the toponaming issue in FreeCAD and a proposal of getting this fixed in the upstream project, with RealThunder’s LinkStage3 fork as a guideline. Since then, we’ve made a lot of progress, but even more work is yet to be done.
Funding free/libre software projects is difficult. For the last 5+ years, the knee jerk reaction has been to say “just do what Blender Foundation does, they got everything right”. But contributors come with different backgrounds. Some are perfectly fine about thinking like entrepreneurs, others would rather stick to programming, or designing interfaces, or bug triaging, or writing documentation etc.