We’ve already introduced some improvements to sketching with constraints before, when Pierre-Louis Boyer implemented contextual constraints. But there are more usability gaps there, and we are targeting them one by one. There’s another major change currently undergoing code review: on-viewport tool widgets to create fully constrained sketches and tool settings to set various properties and choose drafting behavior.
It’s common for vendors to make free licenses available to educational institutions, and while this can be helpful for enabling students to learn the tools of the trade, it can also set them up to learn some hard lessons about vendor lock-in once they go out on their own.
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.
For what shall it profit a man, if he shall gain the whole world, and lose his own soul? -Mark 8:36
Late last year I was talking with Open Core Ventures about the possibility of starting Ondsel. It was exciting to hear from people outside the FreeCAD community who shared the vision that this software was important and could be so much more than it already is. As the idea of actually starting a company took hold, the first important decision was which legal structure the new company would have. Two things that I read deeply affected me and shaped the final decision.
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.