Designing Software in the Open

(tl;dr) Sharing the history of the design of CKEditor, what we learned from it, how we do it today and how you can contribute!

Last year I introduced some details about CKEditor 5, our new content editing platform, which will reach the market in 2016. Since then, we’ve made very good progress with its development. We’re almost finalizing the code for the basic infrastructure that will support the editor’s core.

There is one aspect though that has not been emphasized enough so far — the fact that (since the very beginning) we have been designing CKEditor 5 in the open, so anyone can jump in to help us or to simply share their opinion. Let me share more details about this here.

# Some History First

(tl;dr) A story about the transformation of a one-man-band experience to a community driven project.

# Early Ages: FCKeditor 0, 1 and 2

In the early ages of CKEditor (by then “FCKeditor”), around 2002 and 2003, JavaScript was still an extremely mysterious language. It was used mainly for validating webforms or performing some minor UX tricks, like showing and hiding parts of the page. Back then, thinking about coding big JS applications was crazy, considering the fact that the world was ruled by IE 5.5 and Netscape Navigator.

When it comes to Open Source, it wasn’t such a clear concept for every developer like it is today. Working on the Internet was slow. There was nothing as cool as GitHub to help people code together. Still we had some infrastructure available with the now-defunct Freshmeat and the miraculously still alive SourceForge centralizing the “free software sharing” effort.

In any case, the hands that are writing this article have been put at work and, in a one-man-band effort, the first version of CKEditor was born. I decided to make it Open Source Software so I’ve licensed it LGPL, and eventually published it on SourceForge. It was a CVS project by then, which later moved to Subversion.

Although I couldn’t expect much from the community, especially because of the technical challenge that an in-browser editor was (and still is!) bringing about, going open source paid back immediately. Besides being able to reach a big user base, I got a lot of feedback, which helped making the project better and better.

When FCKeditor 2 works started, a lot of experience had already been accumulated in the project. A nice team of translators started to emerge, helping to localize the editor. Although we didn’t have a big development community, some people here and there started following the project closely and that helped a lot - for example our dear Alfonso, who has been around for more than a decade already 😃

There were some signs that things were being done right. FCKeditor reached one million downloads. It has been awarded the Project of the Month on Sourceforge. A $1,000 crowdfunding campaign to buy a Mac Mini for me to work on Safari compatibility was closed in 2 days. And well… we were having lots of fun!

# CKEditor 3 and 4

For version 3 we decided to make things even more open. We started a project called Open Development Effort (™ 😄) as an “attempt to expand the development of V3 to the public in all its levels: discussions, research, design, coding, documentation, integration and sponsorship”. It was an interesting approach which certainly helped driving the final results. Even the decision for changing the name has been taken there.

CKEditor 3 had two years of great success when we started coding version 4. By then, competition started to be very aggressive. “Let’s kill CKEditor”, they were saying (for real!). So we started to be less loud about what were our plans, especially when it came to Inline Editing, which back then was to be our new killer feature. I strongly regret not being more open with our community, but we made it eventually and CKEditor 4 has been confirmed as a great solution, being even more successful than its predecessors.

# Past Experience: What We’ve Learned

(tl;dr) Make everything around the project open, not only the code. Put things on paper and invite people to participate.

The key things to take out from the above experience were:

• Open Source FTW!: Going open source pays back. You benefit from a much bigger user base, driven by the instinctive human impulse to help and give feedback. The final result is a better tested, more secure and better designed software.
• Stay open from the very first stage: get people involved in the project since the very beginning. The more eyes you have on the design aspects, the better. Don’t assume you know everything.
• Document everything: many times, it is hard to take the right decision. Having a log of discussions in a public place will help you both understand and justify past decisions.
• Wish for quality: while it is easy to make prototypes to “sell” ideas, people may get very disappointed when initial cracks start to show up. Stay focused on doing less but still making a valuable high quality product.
• Don’t care about competitors: there is always this idea that competitors will try to take advantage of every information you make public and try to use it for their benefit. Many actually will. That’s the difference between innovators (you) and followers (them).

Don’t care about competitors. Be an innovator and let others stay behind as followers.

# CKEditor 5: Designing in the Open

(tl;dr) Applying our experience on designing and coding the next generation editing platform in the open.

Bearing in mind the lessons we’ve learned, we’ve started the development of CKEditor 5 last year. Since the very first stage, we’ve been running online discussions about different aspects of the project. Some onlookers started to give feedback here and there but it is time to spread the word to our community.

# The “Design” Place

It was important to find proper infrastructure to be able to design CKEditor publicly. As designing often means prototyping, we had to find a place where we could code, handle discussions and produce documentation. The answer was obvious — we’ve opened up a dedicated repository on GitHub: ckeditor5-design.

The main discussions so far take place in the issues pages of the design repo. Recently, a lot has been done to define the UI and UX aspects of CKEditor 5 (participate today!). Several “low level” coding aspects like whether to go with ES6 Modules or even the usual “critical” coding style discussions have also been held there. If you want to watch our work and (most importantly) contribute to the project, be sure to leave your comments there.

# The “Coding” Place

This may still be a bit premature, but one could also have a look at our code. At this stage there is still no working demo of CKEditor 5, but a lot of critical code has already been produced.

The CKEditor 5 project is split into several separate repositories. To help having things in one place, the starting point is the ckeditor5 repository on GitHub. This repo is mainly the builder and test runner, but it centralizes the workflow for the development team. More instructions can be found in the README file there.

# What’s Next?

(tl;dr) CKEditor 5 is coming! Now is the best moment to start contributing with your feedback. Join us!

We are finally closing the very first stage of the CKEditor 5 development. The basic infrastructure is taking form and we should soon be able to start testing the real editor. The whole team is extremely excited.

As soon as we’ll have something “tangible” to show around, we’ll be talking publicly about specific details of the CKEditor 5 code and infrastructure. Still, this article is to demonstrate that people can participate and help us in designing software that will radically impact the experience of people sharing their knowledge on the web.

Join the CKEditor 5 design repository now!