How SolveSpace Is Retooling Its 3D CAD Open Source Community – InApps 2022

Amazon Web Services (AWS) sponsored this post.

Among open source builders, there are those that take the concept to extraordinary lengths. Whitequark, for example, lead maintainer of the SolveSpace parametric CAD (computer-aided design) software project, had a simple desire: She wanted to build “very boring” technical parts, such as flanges, because “making physical things is cool,” as she put it. For the kinds of things she wanted to build, however, her CNC mill was inadequate; she needed to work with a machine shop, which meant that she required a certain kind of 3D CAD software.

The software didn’t need to be open source. She wasn’t a purist. What did matter was that the software ran well on Linux, was cheap, and would support parametric modeling and NURBS booleans. This narrowed the field considerably.

After experimenting with — and ultimately opting against — FreeCAD and HeeksCAD, Whitequark discovered SolveSpace, an open source project started by Jonathan Westhues. Great, right? Not really. Yes, SolveSpace met some of Whitequark’s core needs, but she says the software was a legacy codebase that was extremely challenging to work with for anyone who was not its original author. This would have turned off most would-be open source contributors.

But for a builder like Whitequark, it was the perfect opportunity to (re)build the digital tooling that she, in turn, could use to build physical tooling.

Finding the Undo Button

Not that Whitequark had ever planned to contribute to SolveSpace, or any other open source CAD software, for that matter. Her passion was building physical objects. The software was just a means to that end.

Whitequark is quick to celebrate the great work open source pioneers had done in the field of 3D CAD. She would have been happy to follow one of them, but for a cardinal sin: data loss. HeeksCAD was “groundbreaking” but lacked an undo feature. This proved a problem given that she found it to be a bit quirky and unreliable. Whitequark thought FreeCAD was perhaps more directly relevant to her needs, but she says, “I never managed to get even a single part modeled in FreeCAD because it crashed so much and destroyed my work each time. If I recall correctly, undo didn’t work well there either.”

Which left SolveSpace.

“SolveSpace was, in many ways, perfect,” Whitequark says. “It was simple and easy to use. It had perfectly — and I do mean perfectly — working undo. It never — and I do mean never — crashed on me, at least until I started improving it,” she continues, self-deprecatingly. But then there were all the not-so-perfect things about it, including that it was written for Windows in a restricted, C-like dialect of C++. No tests. Lots of bespoke data structures with no abstraction and lots of hidden invariants. Not particularly portable. Only supported ASCII. And so on.

“The things that it did, it absolutely excelled at,” Whitequark says. “But it was a legacy codebase that was extremely challenging to work with for anyone who was not its original author, as I quickly realized by discovering that many of my early obvious-looking changes were, in fact, unsound.”

So she got to work, gradually — and carefully — improving the code. By her reckoning, she took two years to become comfortable modifying the code. Westhues, by contrast, was very comfortable with Whitequark’s involvement, and passed the maintainer hat to her.

Assembling an Army

No matter how good a project lead may be, they’re rarely sufficient on their own — not for the most ambitious projects that need to reach a diverse user population. Even as Whitequark was adding usability improvements, such as an improved GTK2 port and native macOS support, she was realizing that the project needed a computer graphics expert as geometric operations required work, the OpenGL 2 immediate mode renderer was very slow, and there was no way to export a 2D projection with hidden lines. “I am just about the opposite of a computer graphics expert,” she admits. “I do cross-platform systems programming, but I can barely multiply two matrices.”

Great leaders leverage their strengths while recognizing their weaknesses, making up for those weaknesses with the strengths of others. In Whitequark’s case, she found Aleksey Egorov, a talented engineer with the requisite understanding of computer graphics and a good command of C++. Egorov wasn’t able to work for free, however, so Whitequark took on contract work so she could fund his work. More recently, to help share the load, she has engaged Ryan Pavlik and Paul Kahler to become co-maintainers.

Even so, Whitequark’s experience is a lesson for any would-be open source contributor. Because the SolveSpace codebase is so complex, it’s difficult for casual contributors to get involved. “The problem is not that there are not enough people willing to write code, but rather that it is too hard to write code that will be reliable and won’t introduce compatibility hazards,” Whitequark stresses. This means that much of the burden of development falls on her, particularly since many in the SolveSpace community tend to be mechanical engineers, not software developers.

Building and Maintaining

Over time, the nature of Whitequark’s work with SolveSpace has evolved, even as it has taught her the importance of going slowly with code improvements so as to maintain backward compatibility. “I used to do a lot more systems programming work than maintenance work, but it quickly became the opposite,” she says. “I still have some grand plans for improving SolveSpace, though. As someone who has spent years learning this codebase in detail, I’m in a perfect position to make sure no one has to spend an equally long time after me. My principles can be summarized as ‘done is better than perfect, but broken tomorrow is worse than not done at all.’ Slow development can be frustrating to users — and alienate a vocal minority — but SolveSpace is here to stay, and I’m going to leave it better than how I found it, even if it means a lower pace of improvements.”

This leads to a critically important insight for anyone hoping to lead an open source project. “Over time, social decisions become a lot more important than technical ones,” Whitequark says.

Code matters, of course, but it will eventually become obsolete. By creating a welcoming community, project maintainers like Whitequark are able to tap into the collective energy of others to ensure the code is refreshed to meet new requirements.

Which is why open source needs more builders like Whitequark. SolveSpace doesn’t boast a huge community and its user population will always be small relative to the size of, say, Linux. There just aren’t as many people using 3D CAD software to build physical objects. This doesn’t make it any less important for those that do build such things, however, and Whitequark’s focus on improving both the functionality and reliability of SolveSpace offers important clues in open source leadership.

Whitequark and others work hard to ensure SolveSpace is a welcoming community. Want to get involved? Pop into the SolveSpace forums. Not ready for that yet? Maybe spend time with a SolveSpace tutorial, then download the application and try building something. Ready to contribute? SolveSpace has made it easy to get started with your first contribution.

If you or someone you know needs help with a different open source project, visit the AWS Open Source site to learn how open source projects can apply for AWS promotional credits.

Feature image via Pixabay.