Intro

We know we have been silent for some time and we would like to correct that now. In this blog post, we want to let you know what we are working on and what it means for the future of Open Design.

Last year was a year of big changes for us. At the beginning of 2021, we launched a preview version of Open Design. Our goal at the time was to see if our vision around working programmatically with designs resonated with anyone else. We set a goal of talking with 30 interested companies to see what kinds of problems they were encountering and if a tool like Open Design could fill some of the gaps. We found that there was demand from all kinds of organizations - from small startups to giant corporations - for the ability to pull data from a design without having a copy of the design software open on a computer.

During our interviews, we heard that security of designs was top of mind for these companies. In particular, the fact that designs were sent to our remote servers to be deconstructed and then converted into the Octopus format meant that they needed to trust us with this sensitive data.

We also understood that for many of the problems that companies mentioned, it would be more practical to have all the necessary parts of our SDK available locally, without our cloud. This was both a technical and business problem for us at the time. Our main product, Avocode, was still our primary source of revenue and it seemed like a big risk to start bundling its core technologies for free to anyone who would use our SDK. We were a small startup that didn't even have a Series A investment, so a stable income was essential for us.

At the end of 2021, a huge change came. Avocode was acquired by its largest Open Design customer, Ceros.

Ceros is also a startup but at a completely different stage and size than Avocode. After seeing how Open Design was able to power Ceros Studio’s import feature, their leadership team started conversations about how our companies would continue to collaborate together. In particular, they saw enormous potential in Open Design’s vision of "Making design accessible to everyone.”, which eventually led to the acquisition.

In pursuit of our vision, we not only want to create software to make design accessible to people. We also want those people to be able to contribute back to that software. Eventually, free of the business concerns that we had before, we’d like to make all of our technology open source. So even if we happen to disappear in the future, or some company that created a design tool disappears, your designs should be able to open and work with in Open Design.

Open Design 2.0

After we became a part of Ceros, we were given free rein to continue to build Open Design in any way that we desired. Our team got to work brainstorming and eventually came up with five areas of focus:

1. We want all parts of Open Design to be open source and available locally - both in the browser and on a private server.

2. We want to fundamentally improve the Octopus file format, which has acquired inconsistencies over many years of development. We also want to extend it to include additional data that had not previously been possible to include.

3. We want our design importers, the libraries that parse the designs, to be written in a language that is possible to run in the browser. This effort involves rewriting a number of our importers from Python into a language like Rust or Go.

4. We want to expand the capabilities of our rendering engine beyond just displaying designs. it should be able to create and edit them as well - and do it on the server and in the browser. In particular, this effort is so large that we’ve renamed the rendering engine to Open Design Engine (ODE) to better reflect its new responsibilities. And of course, ODE will run both in the browser and on the server.

5. From the very beginning, we’ve understood that nothing we build matters if developers can’t figure out how to use it. All of these new components should be bundled into one cohesive package that makes it super simple for a developer to import a package into their project and start manipulating designs.
   
   We would like the API to be high level enough, yet flexible enough, that Open Design can be used as the basis for applications that work with canvas. We resonate quite a bit with the idea of TLDraw author Steve Ruiz, who describes that if software that solves a complex problem is not open source and other companies can't build on it, it limits further innovation in the field.

With these improvements, we’re positioning Open Design as a headless design editor - the best base for projects that want to work with designs.

And this is the current state of the new development:

Completed:

✅ Octopus 3 file format specification

✅ Adobe XD importer supports Octopus 3

✅ Figma importer supports Octopus 3

WIP:

🚧 Adobe Photoshop importer

🚧 Adobe Illustrator importer

🚧 Sketch importer

🚧 Open Design Engine

🚧 Open Design framework (The library that connects everything)

Our team is building Open Design 2.0 in tandem with another internal team using it to build a new motion design application (we’re eating our own dog food). This approach allows us to catch bugs and inaccuracies and improve the overall API quickly.

What are the next steps?

We would like to communicate better with the community, so we want to start writing monthly updates (the monthly updates were an overly optimistic vision. We will write quarterly updates) on progress. From experience we do not want to promise a specific deadline for when everything will be available and in what state of stability. In the coming months, we will gradually start adding GitHub repositories and slowly start updating the Open Design 2.0 website and documentation. If you want to follow updates, start following us on Twitter @OpenDesignDev.