Freedom in IT. What are the advantages of working on your own product? A talk with Piotrek Koszuliński, CKEditor 5 Project Leader
The decision to go towards collaborative solutions was a great success but we obviously made a lot of mistakes, admits Piotrek Koszuliński, CKEditor 5 Project Leader. In our interview, he also shares his thoughts on the reasons why this WYSIWYG editor is so unique and popular and why so many great specialists want to be a part of the team developing it. On top of that, he sheds light on the technical side of CKEditor 5, and ins and outs of creating a top-notch open-source project. Read on for more!
What is CKEditor 5 in a nutshell?
To make a long story short – we develop CKEditor 5, a web-based text editor that is easiest to compare to Google Docs. It allows you to format text, and insert tables and pictures. It also supports the most important functionalities of the “collaborative editing” pool: working on one document by many people at the same time, commenting, suggesting, as well as versioning.
The difference is that Google Docs is a product aimed at end-users, and CKEditor 5 is a component that developers integrate with their systems. For that reason, CKEditor 5 should rather be defined as a framework plus an ecosystem of plugins.
This is already the fifth version of CKEditor. How long have you been developing your product?
We have been operating as a brand since 2003, that is for 19 years. I joined the company in 2012 when there were only ten of us. Today, there are 80 people at CKSource, and 30 of them are working on CKEditor 5 and the cloud part needed for collaboration.
During these 19 years, we rewrote the entire editor from scratch twice. We started working on the “Five” in 2015 with a blank page. The rewrite was risky but necessary and, in retrospect, we can see that the investment has paid off.
The whole process itself was an amazing adventure. Despite having the experience from previous versions, we obviously made a lot of new mistakes. Fortunately, a project of this type is a marathon and we are making a step forward with each new version.
Where can we come across CKEditor on the internet? Can you provide examples of applications and companies that make use of it?
It’s hard to define our scope, as one editor installation can later be used by hundreds of thousands of users. As for downloads alone, there have been tens of millions to date. I think almost everyone reading this interview has had the opportunity to use CKEditor in some application - be it in a CMS, forum, contact form, or internal company application.
Our clients include dozens of global, recognizable brands - Microsoft, IBM, Siemens, Citi, the Big Four of auditors, but also Disney, UNICEF, Philips, Volvo, TATA, Thomson Reuters, and others. This number is constantly growing. The decision to go towards collaborative solutions was a great success.
What makes such large customers attracted to CKEditor?
I think that the first major customers were attracted by the popularity of CKEditor, its quality, and the professional approach of its creator and founder - Frederico Caldeira Knabben.
At this point, we are the market leader and offer flexible, battle-tested solutions. Many years of experience also played a significant role - clients know that they can trust us, and we have strong arguments in our hands that make negotiations much easier.
Can you tell us more about the technical side of CKEditor 5?
The framework was created with collaboration in mind and the “real-time” issue often has a decisive impact on architectural decisions. The underlying technology is Operational Transformation that allows us to solve conflicts that occur during simultaneous editing.
OT is elegant at the core but incredibly complicated for complex tree structures. The recently popular Conflict-free Replicated Data Type seems to be an alternative but while OT has been successfully used in several editors, CRDT has not received such confirmation.
Another interesting fact is that CKEditor 5 was created in vanilla JavaScript. The editor engine must be running at a low level, directly in the DOM. Any generic abstractions would cause problems here.
The frameworks’ lifetime was also an important factor. Today, the situation has stabilized, but if we had chosen the most popular framework when we started designing the “Five”, it would have probably been Backbone.js.
However, it’s not that we avoid frameworks. We revise decisions as the situation develops. For example, we are currently migrating to TypeScript and consider using React in the editor interface.
Can you tell us about mistakes you made when designing the “Five”?
Oh, it probably deserves a separate conversation. In our case, one could even speak of certain categories of errors.
One of them was trying to specify what the CKEditor 5 engine should be able to do. We don’t build a target solution, but a framework. We have to anticipate the needs of developers well in advance. If we don’t predict something, the cost of adding it later can be huge. But if we try to anticipate everything, the project will never be finished. Such balancing is extremely difficult.
An attempt to generalize wherever possible was a derivative of such an attitude. For example, we tried to support all bundlers (i.e. webpack, rollup, etc.). The cost of this was disproportionate to the profits.
Another example is going into the multi-repo. Each package had been developed in a separate repository. This was to motivate us to treat packages as separate entities, a bit like in microservices. Again, the cost exceeded the gains.
Another interesting mistake we made was the project we called Letters. It was our first product designed with total simplicity in mind. It was supposed to be ready-to-use, as well as plug & play (and pay) but it turned out that we couldn’t find customers that would sacrifice the extensibility and flexibility that CKEditor is known for, in favor of ease of use.
It was a good lesson to learn that when starting out with something groundbreaking, you still have to solve real problems, and therefore know your customers.
We try to learn from such mistakes and not make them again. We have to prepare for the next rewrite, eventually.
Is it really possible to employ 80 people when developing an open-source project?
Open source is a software development and work model, not a business model. The code of a large part of the editor is open, which improves both the convenience of its use and transparency, but not everyone can use it for free.
Unfortunately, there is a common belief in the community that open source means sharing your work for free. And while it makes sense for smaller libraries and the most popular grant projects, in many cases this approach doesn’t work, in my opinion.
We sell commercial licenses and offer support and other services. We build complementary “premium” products. We’ve managed to find a clear division between what is open source and what is closed - thus avoiding unnecessary friction. We’ve also become experts in our field and our partners and clients appreciate it.
The product that you offer is rather unusual. And what kind of company are you?
Very normal, I guess. We are not trying to be this or that. We do our own thing, talk to each other, draw conclusions, and change. We strive to ensure that processes are defined bottom-up and decisions are made at the lowest possible level. We create a cool workplace for ourselves and others.
We value long-term and well-thought-out decisions. At the moment, we have two offices in Poland, but our products are sold all over the world and it seems to me that we are better recognized in the west than in Poland itself.
In our daily work, we use Slack, Zoom, GitHub, ZenHub, or Officevibe. Almost all teams, including non-software ones, use GitHub. We also got fond of Notion, where our internal knowledge base is increasing.
And what does the work on an open-source project look like from the team’s point of view?
First of all, we are aware that not one, but thousands of customers keep an eye on us.
The open issue tracker and the project’s popularity mean that the backlog is endless. Ticket handling, evaluation, and prioritization require additional processes. However, the open decision-making process, which we mostly conduct on GitHub, can be depressing at first for some developers. In my experience, however, the community appreciates our analysis, even if we err at first. It is easier to sell a decision if it is supported by honest discussion.
Everything, however, in moderation. In the past, we had virtually all discussions in tickets. This communication model has its advantages, but it is difficult and not very efficient. Today, we talk much more face to face, but we still make sure that the results of the discussions are publicly available.
What I say seems obvious, but it wasn’t easy for us to change some of these habits. At one point, the median length of service in our team was six years. I knew we were living in a bubble and I wanted to change this situation. A good opportunity came in 2020 when we started scaling the team. We try to use the experiences of new people and the last years showed how many great changes we can introduce thanks to them.
Six years in one job is not typical of IT. What makes you work here so long?
This is not one thing. You’re looking for one thing for the first three years in the company, and for something else after a decade.
The basis is certainly an interesting, uncommon, and complex project. We create a framework for developers and face some new challenges every day. Editing text may not sound exciting, but the so-called “essential complexity” we are dealing with is considerable.
Next - the fact that we are a product company. We decide what we do and when we release it. The need for keeping what we do in such a complex project means that we have to take care of quality and skillfully manage technological debt. I’ve learned a lot in this regard - not only how to write code, but also how to make decisions.
Finally - the company’s culture and history. The fact that I can make progress here, work with fantastic people, and have an influence on the design and direction of the company’s development. The open-source model and the scope of the project also give me a wide range of possibilities. In what other company could I be invited to W3C as an expert?
