We’ve completed the first year as employees and contractors paid to hack on FreeCAD and build services around it. We do have a few things to brag about. We also had some setbacks and challenges. Since we started Ondsel with a goal to be as honest and transparent as possible, let’s talk about things the team learned this year while figuring things out.
Being part of the FreeCAD community
The majority of the team — employees and contractors alike — was already involved with the FreeCAD project one way or another prior to the launch of Ondsel.
I was one of the original authors of the Path workbench that I still maintain and I’m one of the founding members of the FreeCAD Project Association. Ajinkya and Amritpal were former GSoC students who continued contributing after the program was over. Pierre contributed to the Sketcher workbench. Pieter created the OSH Automated Documentation workbench. Adrian who recently joined us as contractor had been release manager of FreeCAD for the past couple of years. Alex contributed translation updates and covered FreeCAD news in his blog.
In other words, we understand how the project works and what challenges it faces.
Ondsel and FreeCAD have a shared interest: making the software great, creating a thriving ecosystem around it, and encouraging more contribution. At the same time, we’re different and our differences provide both opportunity and challenge. As a startup, Ondsel has to be commercially successful and it absolutely has to hit certain financial goals in a sensible timeframe. On the other hand, Ondsel can do things that would be difficult or impossible for the FreeCAD project to achieve. Things like SaaS collaboration or CAD “vaulting”. We can bring focused development attention to really hard issues like toponaming and we can more effectively respond to the needs of commercial users.
Our differences also mean that we must operate differently. As a company we need more predictability. If we contribute a fix or a new feature, and it passes code review but never gets merged, our effort and money is wasted. If we want that change for our own customers then our code base starts becoming a hard fork, and those are difficult to maintain with a small team. We want to build on top of the great FreeCAD foundation. We don’t want to fork it. Early on, we asked for a more reliable process where the queue of pull requests gets reviewed on a regular basis and changes are acted on quickly. The community responded, and the merge process is now running remarkably well.
But guess what; It helps the FreeCAD project just as much as it helps us. Contributors don’t really like when their patches are stuck in limbo for years. It hurts morale and drives contributors away.
What worked well and what — not so much
Some things worked amazingly well. The merge process was definitely a huge win for everybody. The queue of active PRs is now commonly below 25 items.
The toponaming project is progressing well despite some tasks taking a lot of time, like the ongoing battle of the TopoShape class with its 94 methods and 5,600 lines of code. The team is now in the middle of the third phase of the project.
The integrated assembly workbench is shaping up really nicely, we are beginning to see users demonstrating complexity beyond what we expected and reporting bugs and requests for improvement. The initial implementation will be minimal yet functional, with a solid foundation for further expansion.
Things didn’t go as smoothly with UX/UI fixes. We’ve had some great results with improving major parts of FreeCAD like Sketcher: new tools, floating input widgets, tool settings, easy dimensioning etc. Unfortunately, UI discussions on the forum and in GitHub issues continue to be emotional and often counterproductive.
To be honest, we — the entire FreeCAD development community — have done a poor job of talking to our users. Too often we’re asking them how they want us to build the application. That’s the wrong set of questions. Instead we should be asking them what they want to accomplish. We should be learning why they need the feature they are asking for so we can implement it in a way that makes sense. It isn’t fair to expect our user base and especially our power users to also be experts in software development. That’s not their role in the community.
FreeCAD was started by software developers who were also experts in CAD. For a long time, the community had many people like this and made great strides but these are rare people. Now our community is much larger and has people with a diverse set of skills and experience. Many of them are using FreeCAD to do amazing things but most aren’t software developers.
As the project continues to mature, we need to embrace this reality. We need to build up a team of experts who can work effectively with developers. We need people with vision, patience, and the ability to communicate the WHY of things.
The emerging design review team in the FreeCAD community as well as Ondsel haven’t yet gained enough trust from the wider community. Building trust takes time. It requires us to say what we’re going to do and then follow through. It requires us to demonstrate competence and humility at the same time. I believe that FreeCAD v1.0 release will help a lot with trust simply because of all the much anticipated features and quality-of-life changes it will bring.
Exploring the viability of FreeCAD as a pro tool
Over the course of the entire last year, I conducted several dozen interviews with users from all walks of life: hobbyists, freelance engineers, small business owners, CTOs of larger companies. The frustrating part is that it’s pretty damn hard to find people who do commercial work with FreeCAD. This is an existential problem for the FreeCAD project and also for Ondsel.
Commercial work is all about turnover, efficiency, and stability. When a software project focuses on building for a commercial audience, the resulting application works for commercial users as well as for hobbyists and other enthusiasts.
Commercial users push development of advanced features and bring resources that can fund that development. But if the project focuses on meeting every niche desire and special case, if it rushes development features that should be more thoroughly investigated and implemented carefully, if it caters exclusively to the enthusiasts, then the result is hard to learn and maintain. It won’t be adopted by commercial users at all.
The project is maturing and it’s time to be more focused on building relationships with users that will demand stability and ease of use as well as advanced features.
In that sense, getting Stephen Hawes from Opulo into the FPA general assembly recently was a smart move. Opulo is a small startup that uses FreeCAD extensively to build their Lumen Pick-and-Place machine.
Takeaways
What have we learned?
Faster release cycles and clear release goals benefit everyone. We’ve seen an overwhelmingly positive community’s response to the idea that releases should be more frequent and more focused. It also helps the developers make decisions based on priorities. It worked well for us in the past, e.g. when we built a release goal around migrating to Qt5 and when we focused on supporting Python 3, for example. These kinds of release goals work. Let’s do more of them.
We need more ‘better’ communication. Both weekly PR review meetings, bi-weekly TNP meetings, and monthly developer meetings were a tremendous success in terms of helping contributors communicate to each other and sync on their plans. Continuing that is a bare minimum.
We need more ‘high expense’ communication. When we did the assembly WB review series and offered a path forward, there was very little unproductive discussion. People mostly got on with that. And now the first feedback we are getting is that workflow-wise the integrated assembly workbench is more or less what people had hoped for. But communicating this way is expensive. There’s a lot of research hours put into this project prior to any coding (which is also not cheap). We need more research like that to help unify vision and clarify goals.
The project needs more trust between stakeholders. The FreeCAD project has been going through massive changes for the past few years: new faces, new unusual roles, a non-profit organization backing it, the first company building around FreeCAD commercially etc. This is a lot to take in. We need to find a way to communicate better with each other and build stronger relationships to succeed.
The ‘commercial’ user base of FreeCAD is too small. The perception among commercial users is that FreeCAD isn’t ready for real work. We think otherwise. Ondsel doesn’t have to be all things to all users. It is perfectly capable of meeting many needs that commercial users have now. What’s required is a focus on exposing that capability to a wider audience of commercial users and a focus on minimizing the weaknesses as fast as possible. If we want FreeCAD to excel, we need to talk to people who use CAD programs for work, and we need to do it all the time.
What’s next?
Our plan is to release a build of FreeCAD that is targeted at commercial users — with more polish all around and an initial version of the integrated assembly workbench, as well as with collaboration and sharing tools.
We have more interviews already scheduled and we’ll continue listening to users — those who succeeded using FreeCAD for work and those who struggled and chose something else instead. We’ll also invest more time into strengthening our relationship with the FreeCAD community.
For now, you can grab the latest Ondsel build of FreeCAD, give it a spin and join our Discord server to tell us about your challenges.