Artur Arseniev is the creator of GrapesJS, a free open source web builder framework that allows users to build HTML templates without coding.
Artur lives in Italy. Apart from managing GrapesJS, he also works as a senior front-end developer for Casa.it and manages his own SaaS product, Grapedrop.
What did the early days of GrapesJS look like?
I'd say unexpectedly great! When I first published this repository on GitHub (around January 2016), I knew the tool was only made for a particular niche, so it wouldn't spread easily by itself.
To counter that, I pinged some friends and other front-end communities, but except for some cool feedback, nothing extraordinary happened. Then I posted about the project on Hacker News (YCombinator), but there was a lot of activity that day and my post got buried.
Fortunately, I soon got an email from Hacker News about an opportunity to be placed in the second-chance pool so my post could be viewed directly on the Hacker News home page. This skyrocketed the visibility of my project, and in just a few days, GrapesJS was on top of the trending list in GitHub with thousands of stars.
How did you encourage people to use GrapesJS?
To be honest, I've never outright encouraged people to use GrapesJS, it's all been done organically.
This probably happened because the project was published during a period of great growth in website builders and people were trying to find some open source alternatives.
We have two kings of users—the ones who just want to play around with the demo and build some webpage/newsletter, and those who want to create and integrate a custom web builder inside their applications.
How do you plan out your work? What’s your style of preparation?
I'm generally the kind of person that prefers to start acting on things as soon as possible. Unfortunately, this approach doesn't fit well into the long-term vision for our work (it's probably applicable when you need something like an MVP).
What I've started doing in the past few years, when I face a new task, is to start thinking from a top-bottom point of view. Whatever is a new module, library, or any kind of feature, I start to design the final result of it (with a TDD approach), like how I'd expect to use it as a consumer.
Indeed, I'm doing a lot of refactoring right now in GrapesJS, just to fit this model in, as some of the APIs were made more with a self-oriented style than user-oriented.
If you could go back in time and advise your younger self, what would you say?
I'd definitely tell my younger self to share my initial idea about the project from day one itself.
When I started working on it, I was just trying to solve one problem—but now I realize I need to solve a more generic one with a wider point of view. Had I known this at that time, I would be spending less time refactoring the project now.
Were there any low-points or roadblocks? Did you ever think of stepping away from the project?
Well, I think in any long-running project you will face a lot of ups and downs.
In the open source world, this is even more common. People often need to step away from projects due to time unavailability, a lack of resources, etc.
But, besides all this, I was lucky enough to be able to keep working on this project without any serious blockers.
A big part of the experience is also learning how to handle and defeat obstacles during your work, so you should take those problems as a challenge to beat and make them feel more like a natural event.
How important is testing for your project? What tools do you use to test?
Testing is as important for my project as it is for any other software project. One good thing we did for GrapesJS (that I'm really proud of) is to have started testing functionalities right from the beginning.
A good test approach leads to a more stable code structure. Tests push you to create your functions in an isolated and pure manner. It's also much harder to apply tests later than in the beginning.
The main benefit of testing, in my opinion, is to make the developer more confident with the code. The fear of breaking something is real and this is one factor that drives people away from contributing to open source projects.
Most times, just a few days' break is enough to make you forget specific functionalities you have created before, so it's hard to keep everything clean and stable. This is where tests help—they serve as a reminder to let you know where the structure is breaking up.
I can also confidently say that testing GrapesJS properly saved me hundreds of hours from trying to fix bugs. They also made each release more stable for users.
As for the tools I use, I usually use the amazing Jest framework (which is now a de facto in web software development), which is super easy to set up and run in your terminal during development.
Test commands are also bound to Travis CI, a continuous integration service, which is triggered at any push to the repository.
Another important companion is obviously BrowserStack. Working in web development, one of the biggest challenges is to make your software run consistently well across all supported devices and browsers, which may highly differ in functionality. BrowserStack allows me to reproduce and debug those issues directly from my browser by switching only the virtual environment. Without it, it would be impossible to work on those bugs. Of course, I could always ask the reporter to try each fix on their own device, but that would be an awful experience.
How can new open source projects build a supportive community?
Well, I think this might depend on many different factors. The first one is the nature of the project itself—most open source projects are here to solve some kind of problem. So if you're able to find the right target, the community will soon grow organically.
The next point is documentation—you can't pretend your users understand the project by reading the source code. You have to give them the fastest way to do it. If you want people to contribute more, you'll have to provide documentation for developers where you explain how your code is organized and how contributors can help improve it.
Unfortunately, making documentation is not easy. GrapesJS didn't have any when it was first published and that was a big miss for a long time. Even now, there are a lot of things that need to improve.
The third thing (which I've already emphasized) is the importance of coverage in your tests. The more you have, the more confident you can be that your community will contribute.
Obviously, apart from that, there are things like better communication and marketing that might increase community contribution.
Have you worked on any other major open-source projects? Which ones and why?
Not really. I've made a few little fixes for some other libraries and published tiny projects I created just for fun, but nothing more than that.
I started my open-source journey with GrapesJS and this has kept me busy since then—and, to be honest, I don't regret it. I prefer being focused on one specific project and avoiding context-switching.
Did you ever feel like you were close to burnout? What do you do to prevent/avoid burnout?
Unfortunately, this happens to me from time to time. Since I am also working on other projects simultaneously (a full-time job and my own new SaaS platform Grapedrop), I am faced with struggles and stress every time something doesn't go exactly as planned (which is quite often). This immediately decreases my motivation and enthusiasm to frighteningly low levels.
To prevent this from happening, I do exactly what others do. I take a break from the work, do everything else except for working on my laptop (usually, a few days are enough), and spend more time with my family and friends.
After a few days of the total absence of work, I start to focus on my goals and think about how I can achieve them. This helps bring back the motivation and enforces me to organize my job better.
Check out GrapesJS on GitHub.
We ❤️ open source. Fill out this form to get free, unlimited access to BrowserStack for your project's testing needs.
(Responses are edited for clarity).
Recommended reading
