Three weeks ago, we launched Revideo, a framework for programmatically creating videos. Even though we’d only been working on it for a month at that time, Revideo was already quite far along and feature-rich. This was not due to us pulling all-nighters for an entire month straight. Instead, we had a headstart by building Revideo as a fork of an existing open source project, Motion Canvas.

Generally, forking an open source project is not considered cool. Why would you create a separate project and force people to choose, when you could instead just contribute to the original project and let people profit from the work of all parties?

As expected, we received some backlash on Twitter from a maintainer and other users of Motion Canvas:

Even though we expected backlash and the tweet didn’t really reach a huge audience, we panicked and felt pretty bad. The initial decision to create a fork was not thoughtless, we had spent a lot of time looking for ways to achieve our goals without doing so. Still, this mini Twitter drama (which felt like a huge PR crisis to us) prompted us to reevaluate and think about our decision.

We came to two conclusions:

• We still believe that forking Motion Canvas is the best practical way to build Revideo. With “best”, we do not just refer to our gain as a company, but for the developer community as a whole.
• A lot of our initial communication oversold our contributions and did not give Motion Canvas enough credit. This is something we are doing very differently now.

We want to use this post to share some thoughts on why we believe that forking is justified, and to clarify our goals and intentions with Revideo.

In the beginning of 2024, we pivoted away from LLM finetuning-as-a-service and started to explore the space of AI-enabled video editing and creation. We talked to some people in the industry and thought about a few use cases such as automatically A/B testing and personalizing video ads. In the end, we got started by building a simple web editor for short-form content, with a heavy emphasis on pre-defined templates of popular video formats and memes.

For example, we provided a template that let people create the “famous people playing Minecraft” meme by uploading images, voice snippets and a dialogue:

Another template we offered let you create Youtube Shorts just by providing a topic. Here is an example for the topic “animal rain”:

While building the app and exploring other ideas, we were consistently frustrated with the video editing frameworks we used. We initially started building on top of Moviepy, but quickly ran into two main issues:

• Moviepy doesn’t have an option to preview your videos. Therefore, to look at the result of your video, you needed to wait for it to be exported, and thus had to wait huge amounts of time to test your code changes.
• More importantly, since Moviepy is not web-based, it didn’t have built-in functionality to do any editing in the browser.

Due to these issues, we later switched to Remotion, which we were quite happy with. However, a big issue for us and the reason why were reluctant to use it was the fact that it is source-available, but doesn’t have an open-source license. Instead, they maintain the rights to their code and require you to pay when using Remotion as a company.

We think that Remotion’s pricing is very fair, and would have been okay with paying them. What put us off instead was the dependence on a codebase owned by a single company. In terms of “vibes”, it just feels better to use open-source tooling, particularly if a big part of your product depends on it. Furthermore, we did not want everything that we built to require purchasing a Remotion license: In case another company wanted to build on top of our repository, it would mean that they would have to pay Remotion too. Similarly, if we were to offer services or let an enterprise customer deploy our app by themselves, they would have to make sure to comply with Remotion’s license. Since it was the only viable option for us, we did build our MVP on top of Remotion, but planned on switching once we found an alternative.

While we thought that our video app was fun, we were not really sure if we could turn it into a business. Me and my co-founder are both engineers and have always been more interested in building tooling than consumer products. Given that we had been frustrated with the tools we tried, we decided to build the video editing framework we’d been looking for in the last months ourselves.

At the time, we already knew Motion Canvas and really liked its API for building animations. In fact, we had spent some time evaluating whether we could use it to replace Remotion for our web app. When we did this, we noticed that it lacked a lot of the functionality we had gotten used to from Remotion. For example:

• Rendering could only be triggered through the Motion Canvas UI. Obviously, you need this functionality exposed through an API to build apps.
• The audio stream of video elements was not exported when rendering videos.
• Motion Canvas does not allow you to edit or sync audio files in any way. The only thing you can do is lay a single, pre-made audio file over the animation you’re trying to export.
• Video exports are very slow when dealing with video-in-video.

We saw two options at this point:

1. Start from scratch with the goal of trying to build something similar to Motion Canvas, and probably spend more than six months to even get close to an MVP.
2. Extend Motion Canvas and ship something useful in a month.

Understandably, we went for option 2.

After deciding to extend Motion Canvas, we tried to figure out if we can build what we wanted without forking. Motion Canvas has a plugin API, but it is unfortunately not flexible enough to integrate the functionality we wanted Revideo to have.

Lurking in the Motion Canvas Discord, we noticed that the maintainers are very strict about what they want Motion Canvas to be. They have a clear vision of the tool and are not interested in adding features that are not in line with it. For example, they have repeatedly stated that they do not want to add audio support to Motion Canvas, as it is a tool for creating animations and not a video editor. Many of the changes we wanted to make (e.g. headless rendering and audio support) were proposed but repeatedly deemed out of scope. As stated on the website, the maintainers see Motion Canvas as “a specialized tool designed to create informative vector animations and synchronize them with voice-overs. It's not meant to be a replacement for traditional video editing software”. Clearly, we had different opinions, as we wanted to build something that covers the full functionality of a video editor.

Another big difference is that the Motion Canvas maintainers don't want people to use Motion Canvas as part of their software stack but as a standalone tool. The fact that it is an npm package is merely for the purpose distribution, and not because it is a package in the traditional sense:

Of course, this is totally fine - but we want to do different things. We want people to use Revideo as part of their own apps, and expose the functionality through APIs. Given this, our contributions would have likely been conflicting.

Motion Canvas and its maintainers have every right to do whatever they want with the software that they have built. It is not at all our business to tell them that their tool should be usable as a library. We just think that Motion Canvas would be really useful as part of other people's apps too.

We understand that some maintainers & users were upset about how we communicated our fork. We have to admit that we did not do a good job at this.

This is what our landing page looked like when we launched Revideo:

Notice how we call Revideo “our framework” and don’t mention Motion Canvas at all? That was pretty inconsiderate. We have now fixed our landing page according to the suggestion of a Motion Canvas user.

In general, we have changed the way we present Revideo. Instead of calling it “our open source video editing framework”, we mention Motion Canvas and say that we are building tooling to programmatically create video using Motion Canvas’ API.

It was wrong to assume that positioning yourself as a supplementary tool to another popular piece of software would make it difficult to build a “brand”. NextJS, for instance, is very well recognized, and it calls itself “The React Framework for the Web”. Nowadays, we find that many people reach out to us exactly because they know and like Motion Canvas and want to build video apps on top of it.

To sum things up: We are big fans of Motion Canvas and the work its maintainers are doing. We think we have messed up communicating the fork initially, and are sorry for that. However, we still believe that forking was the right choice, as

• managing our contributions would be a logistical nightmare
• the goals of Revideo and Motion Canvas are very different and even conflicting

If Motion Canvas’ plugin system becomes more extensible, we are happy to build our features as plugins so that people do not have to choose between Motion Canvas or Revideo. In the meantime, we are going to continue working on Revideo and keep it MIT-licensed, with the goal of enabling developers to build video apps with Motion Canvas.