The nature of a start-up is that there is always the possibility that the start-up is aborted if the concept or ideas don't work out as expected. I've always took this possibility into account with Ondsel, my biggest client up until now, but when it actually happened, it was clear that I was less prepared for it than I thought.

One reason is that I simply enjoyed working for Ondsel very much. I liked the idea, the team was great, and I really wanted Ondsel to succeed and to be able to provide services for commercial parties.

Another reason was that I saw the potential of what Ondsel was offering and with that I mean mostly the ability to freely exchange parameterized CAD files online. This means that users look up designs on a website, edit parameters of the design, for example the width and height of a box, and then download that model or use the model directly as a component in another CAD model.

Finally, it feels as if the work was a bit for nothing. The software and service may be abandoned and that doesn't feel right. You can read more about the shutdown on the Ondsel website.

Ultimately, I believe there is a mismatch with what the investors of Ondsel wanted and what Ondsel could deliver. The investors wanted to provide a cloud service based on the open source CAD program FreeCAD and scale up this service to a level that is highly profitable. This would be similar to the model that GitLab followed, using an open source program as core (Git) and provide a service on the enterprise level around this.

While this works well for the very mature and purposefully for internet-exchange designed program Git, I believe this was asking too much of Ondsel and FreeCAD because FreeCAD is a desktop application that was never designed to support a service.

However, this doesn't mean that Ondsel can't be viable commercially! I think Ondsel as a consulting company that is an expert in FreeCAD development could make a viable business supporting other companies that use FreeCAD commercially. However, this is not the level of scaling that the investors of Ondsel sought, so they took their losses and stopped financing it.

It's unfortunate that Ondsel can't continue, but let's look back at the positives. I feel honored and privileged that Brad Collette took me in as a team member (although being self-employed). I find his leadership very refreshing, open-minded, open to the team, and Brad wasn't shying away from making difficult decisions while still listening to the advice from the team. I think the investors couldn't have picked a better person to try the endeavor that Ondsel was.

The team was also great to work with. John and Amritpal were working so efficiently together on the Lens service. I often had to go back-and-forth with Amritpal and John about the Lens API that the Ondsel Addon was making use of and more often than not, we could come up for a good solution for both the Lens service as the Addon. In the last couple of months I loved working with John on the addon. I think it was a very good match in which I'm quite conservative and implement new features by changing as little code as possible, whereas John just comes in and makes big changes, restructuring the code. Two different approaches but it was very good to be able to discuss direction with someone who also was actively working on the code.

I took over the Addon development from Pierre so he could focus on the Assembly workbench. He and Aik-Siong created a beautiful Assembly workbench where Aik-Siong applied his extensive math knowledge to the solver and Pierre his expertise in coming up with great solutions for assembly with respect to user-experience.

Alex was great in connecting me and the other developers to users and writing amazing blog posts together with Brad. Adrián also helped out in so many ways. He always seemed to have a very good view of who was working on what in FreeCAD development and he often was able to pinpoint problems that we were having to concrete issues in FreeCAD's issue tracker.

Let me finish this post with a small video of one of the things that Ondsel worked on and that I call the Grand Vision of Ondsel Lens which I would summarize as Exchange of Parameterized CAD Files by means of Open Source Software. With that I mean creating CAD models that can be easily shared online and used as models directly in other designs as internet resources.

With Ondsel we are more and more focusing on what Brad Collette calls downstream uses of CAD. Within companies or other organizations, there are many use-cases where people want to use CAD, for example inspecting CAD files for maintenance of machines, creating assembly instructions, or showing designs to customers. These use cases need the ability to view CAD files, but a full license from the big commercial CAD vendors is likely too expensive for these use-cases. This could be a market where Ondsel fits in well.

Since the commercial CAD vendors have such a dominant position, it is then likely that Ondsel ES or FreeCAD needs good support for showing STEP files. In general, FreeCAD can handle STEP files well, but Brad had a great idea that fits well with Pierre's work on the Assembly workbench, namely reloadable objects. A reloadable object is an object that points to a STEP file or a STEP URL. When the file or URL is updated, the user is notified that the reloadable is out of date, and the user has the control to update the reloadable with the new STEP file.

Brad created the initial implementation of it and I incorporated it into the Lens Addon. We both added more improvements, so it was a nice collaboration. Below a video of the functionality.

One feature I implemented for the Ondsel Lens addon that was very interesting to work on was opening custom URLs. The main idea was that people browse to Ondsel Lens, view public share links and click on a button to open the file automatically in the desktop application Ondsel ES or FreeCAD. Most people may know this from Zoom links that automatically open the Zoom application on their computer. We wanted the same, but then for public share links on Lens and opening them in Ondsel ES.

The requirements made this very interesting as well. We did not want to hard-code this into Ondsel ES, because we wanted FreeCAD to have this functionality as well. Because FreeCAD is an open source project, we could only contribute generic code that should have use beyond our use case.

A second requirement was that it should work on all platforms. This means that it should work on Linux, Windows, and Mac OS. Since this should work without Ondsel ES being opened by the user, we need support from the operating system as well to open our custom URLs with the Ondsel ES application.

A further requirement was that the Ondsel Lens Addon should be the handler of our custom URLs. Since the addon is a plugin without much rights, this was a very interesting problem to work on.

To give an idea of the various components and interactions: The user uses a browser to visit the Lens service. The user has Ondsel ES installed, but Ondsel ES may not be open yet. The user browses through the public share links of Lens and wants to open a file. The user clicks on a button in the website, the user is presented with a question whether to open this in Ondsel ES. If the user clicks yes, we need the operating system to know that our custom URL belongs to the Ondsel ES application. The operating system opens Ondsel ES and provides this with the URL. Ondsel ES should then analyze the URL and understand that the Ondsel Lens Addon should handle this URL. If the Ondsel Lens Addon receives the URL from Ondsel ES, it should request the Ondsel Lens to open this file.

Below a demonstration. Note that I manually insert the raw "ondsel" protocol into the URL. This URL should never be seen by normal users, but this is the underlying URL scheme that is used such that operating systems know that Ondsel ES should be opened. The Lens service currently has no support for this yet, but if this support is implemented, users can simply click on a link.

As a member of Open Source Ecology Germany (OSEG) I was honored to be asked to give a presentation about Open Documentation Standards and Open Toolchains at the 2024 Free Silicon Conference (FSiC) in Paris. OSEG was a driving force in setting up the DIN SPEC 3105 standard and unfortunately Martin Häuer who is really the expert here could not attend, so I was asked to present this topic to the FSiC community instead.

As I said, I was very honored and I gave the presentation from the role as a member of OSEG and of the Open Toolchain Foundation. The conference was amazing with very interesting talks that were well received in general. The main point of my talk (slides and video are available) was to introduce the DIN SPEC 3105 standard to this community in the hope they can evaluate what open source means for free silicon.

The first question that was asked as a reaction to the presentation was quite negative, along the lines why you should do the extra work to adhere to a standard whereas the work is already public anyway in a git repository. Unfortunately, I didn't have the best answer to this, but I had a discussion the day after with one of the committee members who was critical and had the opinion that something is either open (if the license is correct) or not. I think I was able to convince him of my viewpoint in the end:

My viewpoint is that the goal to release something as open source is to share it with others, making it available so people can reuse. There is a degree of how useful something is to others. In particular if there is no form of documentation, a publicly available repository may require a process that looks like reverse engineering to uncover the knowledge that is captured in the project. Providing high-quality documentation can make the knowledge much more accessible. Having a standard that defines what high-quality documentation is, especially one that can adapt to the needs of the project like DIN-SPEC 3105 is very valuable to have.

Yes, this can be considered overhead compared to just releasing a project. But, if a released project is not accessible because of lack of documentation and it is very difficult to extract knowledge from it, you should ask yourself how valuable it is.

After my talk many others in the audience came up to me to give me support for this cause. It seems that there are people in this community that have a conservative view of what open source is and there seems to be others that understand that publishing something with an open source license is not enough. To be honest, I was a bit disappointed with the outcome of the presentation, but Martin Häuer had a great point in that this was probably exactly the kind of discussion this community needed.

I hope FSiC can continue this discussion and perhaps even adopt the standard with defining their own set of Technology-specific Documentation Criteria. A very big thanks to anyone who showed interest in the talk and to Timm Wille, Martin Häuer, and Martin Schott who helped me set up this presentation.

An interesting topic that is not hard-core software development is user stories. I noticed that user stories are currently not very helpful to my client Ondsel, so I rekindled my Business Modeling and Requirements Engineering skills a bit and analyzed the existing user stories.

After my analysis I came to the conclusion that persona's and user stories are mixed together. It is not possible to separate the persona from the user story and define a new user story based on the same persona. The user stories did also not seem to be based on research but this is understandable within the context and time frame of Ondsel.

A third problem was that the cards for the user stories were not designed for two week sprints and finally, although the cards seemed very concrete, it was questionable to which extent the cards could drive and direct the software development.

My recommendations tried to take into account the unique position Ondsel is in. It is a company that is dealing with open source software with a large community and since Ondsel is a start up, it is difficult to perform user research that captures the needs of the typical end user. Ondsel will likely not have enough data for that.

In addition, Ondsel's priority is currently not the end user per se, but more managers inside companies that can make the decision to become a client to the services for Ondsel. Persona's do not seem to be the correct abstraction here. So, after trying to define better persona's, I noticed that I was thinking in terms of groups of employees inside a company that could be a client of Ondsel.

This led me to introduce a new term similar to Persona's that I call Compona's. The definition of this term would be "A fictional, detailed representation of a target company for a service, based on research and data. A compona typically represents a group of companies that is made identifiable by choosing a fictional company that fits that group".

After this, I could define several "Compona's" that gave us much more insight in how Ondsel could be of value to these kinds of companies. Given this list of compona's, I established a list of companies that already used FreeCAD and try to fit it into the list of compona's.

Finally, I created a table for each compona that listed for each one what 1) the market share of the compona was, the "service provision likelihood" (to which extent can Ondsel provide the compona with a useful service), and revenue generation potential. This analysis gave us much insight into how to target companies for clients.

I've recently started mentoring for the FreeCAD Google Summer of Code project "Command-Line Preference Manipulation" by Harshita Saraswat. The goal is to create a command line program that allows you to inspect and manipulate FreeCAD preferences. Since I'm dealing with FreeCAD preferences as well to store them in the Ondsel Lens service, this aligns well with my current interests. I'm looking forward to guide Harshita in this project together with Ajinkya Dahale with whom I'm co-mentoring this project.

In the previous post, I discussed Custom Data Elements and the VarSet implementation that I proposed. The VarSet PR resulted in quite some discussion and rightly so. It is a big change and I'm not very happy about the implementation either.

In this blog post I want to show another (too big) PR and proposes my take on improving the workflow with properties in VarSets. Often as a user, you want to reference or create properties in some spreadsheet or VarSet. To facilitate modular design, you may have several VarSets with properties inside. This makes it challenging to understand which property you want to choose.

I want to suggest a construct that allows users to define a "scope". The scope helps the user to confine auto completion of properties to VarSets/properties in the scope the user is interested in. Users may want to refactor properties in VarSets as well, so it would be good to have a property manager that allows the user to filter properties, add properties, and assign values.

To accomplish this, I worked on a Property Manager that allows you to do that. A video of the functionality:

This is a big PR and it rearranges pre-existing code. I chose to copy that code and change it, but this is not a good solution for the long term. The ideal situation is that this code is not copied but is adjusted to support both use-cases. However, that is a big task.

Although my client Ondsel was initially happy with the functionality that the property manager offered, I think it was not completely clear that it would constitute such a large change in the FreeCAD ecosystem, so I was asked to essentially leave the PR as draft and implement a solution that was much easier to integrate into the FreeCAD code base. Below a short video of this functionality.

For me this is a big learning point and it reminds me of the way I used to conduct research. I typically don't like incremental research but I am more in favor of executing a grand vision. In academia, most research is very incremental and I fully understand that this gives researchers much more control over a successful end result. This is also important to researchers, because competition is extremely high and the ones doing the actual research, PhD students need to acquire their PhD to be able to advance in their career. Yet, in my opinion, especially research should allow you to take risks and work on a grand vision simply to allow you to uncover new knowledge.

Now that I'm working on open source software, I understand that the "grand vision" model is not very fitting. Yesterday I had a meeting with Yorik van Havre about the VarSet PR (thanks Yorik and Shai for your willingness to discuss this!) and he explained to me that since FreeCAD is a community-driven project, the code has to be understandable by the community as well. The best way to do this is to have incremental changes. So, this is an important lesson and I think it is necessary to adopt this approach and work towards a bigger vision in small steps.

One such small step that does have a large impact in my opinion is what I call "Direct properties". I typically find the workflow with spreadsheets in FreeCAD very annoying because my design process is constantly interrupted because I need to add a property to the spreadsheet before I can use it in the design. With VarSets and Direct Properties, you can add properties in VarSets while you are designing. A video of this:

Last weeks I worked on what we call Custom Data Elements at Ondsel. One of the problems for Ondsel with FreeCAD is that there are various ways to parameterize designs: You can use spreadsheets, the DynamicData workbench, Path workbench has something for parameters, and Assembly 4 also has its own way for parameterization. On the Ondsel Lens service, Ondsel wants to make models available that users can parameterize or configure, but that is impossible to do if there is no standard way to do that.

I have been thinking about parameterization in FreeCAD for a long time and I've always wanted to improve on it. In this comment on GitHub I describe the problems that I have with how FreeCAD handles this and talking with Brad Collette in person about this idea led to me being hired by Ondsel.

I created a video that discusses the problems with parameterization:

My take on it is called Variable Sets and the idea is that a VarSet can hold various properties, a set of properties. Different VarSets can represent different configurations and switching between "equivalent VarSets" results in a different configuration.

In addition, it should be possible for users to express design intent in the way CAD models should be parameterized. My idea is to make VarSets special in such a way that users can indicate that they want to "expose" the properties of a VarSet. This allows users to communicate how they want their model to be parameterized in something that is similar to an API, an Application Programming Interface. For my VarSet work, I call it an Application Geometry Interface.

Implementation of this was very challenging in FreeCAD and I had various possible implementation directions. In the end, I chose to implement the above functionality as much as possible with the logic that was already available in FreeCAD, by means of copy-on-change links, subshape binders, and hidden references.

This leads to an implementation that I presented in this PR:

I'm not very happy with this current implementation and I would love to see a better foundation to support the Application Geometry Interface.

This week I'm in Brussels where I participate in FreeCAD's hackathon, the FreeCAD day, and FOSDEM. I'm looking forward to meet other developers in person and hopefully users as well! Although remote work has never been so good as nowadays, somehow meeting in person beats everything.

Last year I participated at the FreeCAD day as a member of the Open Toolchain Foundation together with our team. I believe the common feeling was that the meeting was very productive. Perhaps most notable was the "complaint session" where very valid points were made. From my point of view, many things have changed for the better, for example it is very impressive how much code is being merged right now.

During this year's hackathon I hope to discuss and continue to work on the second topic as part of my Ondsel contract, which is managing data for parameterized design in FreeCAD. During the Fab Academy program I started to notice a pattern in my designs where I use sets of variables that are related. For example, there are constants, parameters, clearances, tolerances, and variables that are often a combination of these.

I also noticed that the common workflow for managing data through spreadsheets is quite cumbersome and that FreeCAD is lacking in terms of modularity of designs. I discussed all of this with Brad, Ajinkya, and John from Ondsel and I am now working on this very interesting topic.

I've just submitted an issue that discusses the problem and I created a small pull request that already explains all the plans that I have. The ideas currently receive some push-back from the community, but it is good that the community is critical (as long as the comments remain constructive), because this would become a core feature. I get encouragement from these kinds of comments and I hope that I can show the community the potential soon, because it is now still very abstract. Hopefully, when the proposal becomes more concrete, we can find a solution that has broad support from the community.

Besides all this, on Saturday I will also be representing the Open Toolchain Foundation at FOSDEM. The FreeCAD Project Association was so kind to share its booth with us and also with Ondsel and KiCad. Finally, on Sunday, I will present my work on OSH Automated Documentation at the Open Hardware and CAD/CAM devroom.

So, a busy week, but a very interesting one! Feel free to reach out or come talk to me!

I'm happy to announce that I've just started a couple of weeks ago on my first contract with Ondsel! Ondsel is a young startup that provides a collaborative platform called Lens based on the open source CAD program FreeCAD. This platform allows you to share and collaborate on designs created with FreeCAD.

Ondsel is continuously developing and improving the Lens platform. A couple of days ago the platform had a major update with shared and open workspaces for collaboration. Besides the Lens cloud platform, Ondsel also provides the Ondsel Lens Addon that allows you to work on CAD designs directly from Ondsel ES or FreeCAD. For example, the addon allows you to download designs, it shows you version information and allows you to upload new versions to the Ondsel Lens service.

My first task was to improve the Lens Addon to allow for directory structure, multiple workspaces in different organizations and sharing workspaces for collaboration. This required quite some changes and good communication with the team working on the platform.

Below a screenshot of Ondsel ES running with the updated Ondsel Lens addon. At the right side you can see the addon and a list of the workspaces in my account.

In the following screenshot you can see that we can switch between versions showing commit messages and showing a preview of the model.

Since we working to a concrete release date without much time to realize all the functionality we would like, it made sense to make very clear what the priorities were. We used the MoSCoW method that forces you to categorize the functionality in "Must haves", "Should haves", "Could haves" and "Won't haves". Ondsel makes use of Trello for Kanban cards and it had good integration for the MoSCoW method.

This technique helped us enormously to pin down what we wanted and to remain within the given deadline. Below a small video that scrolls through all the kanban cards I implemented on one of the days right before the deadline:

Although we envision much more functionality for the addon, this major update has been successful!