React-Admin

When you create something you love, it feels good to give it away for people to tinker around and do great things with it. That is what is open-source is all about. But what happens when the cost of maintaining an open-source project becomes too high to sustain? Some people would abandon it, but not Francois Zaninotto, CEO of Marmelab. Realizing the untapped potential of React-Admin, he managed to build a sustainable business model from an open-source core. Find out how he did it in this conversation. Plus, get a glimpse of his other project, GreenFrame.io, which allows users to estimate the carbon emissions linked to user scenarios on a web application and use that information to create a carbon reduction strategy.

---

In this episode, I'm talking to Francois Zaninotto. Welcome, Francois. We talked about this earlier. We have similar backgrounds with regard to agency life and open-source life. Do you want to introduce yourself and give us a little bit of background on where you've come from and how you find yourself here?

Thanks for having me on the show, Ben. To give a bit of background, I'm a Software Engineer. I'm French and I've been working on the internet since I started working back in 1994. I'd say the internet was very different at that time. I worked for various large and small companies, mostly as a project manager. I came back to programming in the mid-2000s and I joined a company called Sensio Labs that edits an open-source framework called Symfony, which you may have heard of. It's the most well-known and most used PHP framework in the world. At that time, Symfony was an internal project, and the CEO of the company told us we were going to open-source it. It was 2006 and open-source was nascent.

It was something very different from what it is now. It was crazy giving away the work you had patiently built for months. We were very surprised at that time and we understood the challenges that represented, like writing extensive documentation and providing support and maintaining over the years, etc. We did it and it was a blast and a revelation for me as a new way to do my job and business by giving away code. It’s something I would never have supposed before. I contracted the virus at that time and it has never left me since.

I founded my own company a few years ago. It's called Marmelab. It's a web agency and we're focused on developing innovative projects for our customers. Part of that job is to develop admins. Every web project I've worked on, I’ve worked on as an admin and it can be a simple view to the database. It can also be a full-fledged ERP where the customer puts all the knowledge of the company that they have.

These admins are the most basic from CRUDs. Around the year 2015, all the projects we were building were API-centric. We started by building an API and then we built the front end as a single-page app. We then had this API and we had to build an admin. We thought we needed a way to build an admin on top of an API.

It was 2012, and we built a tool and it was called ng-admin because, at that time, Angular was all the rage and it was quite popular. When Angular 2 went out and invited everyone to move away from Angular 1, we migrated to React and created React Admin. I'd say it's somehow the 4th or 5th admin generator I have built. It contains all the other learnings or lessons we've learned along the years about how to do admins, B2B apps, and do open-source as well.

Going back to Symfony, I'm curious to know, was that straight out of the gate hugely successful, or did it take time to become the monster that it is now as far as an open-source project is concerned?

It took time, but the popularity was very high right away. There was a big expectation as to what framework at that time. Ruby on Rails was super popular in the Ruby world. Many people tried to replicate the same in PHP. You may remember this time when in JavaScript, we had one new framework per week. At that time, in the mid-200os, there was one new PHP framework every month. When it came out, Symfony was one of those, KPHP and Zen Framework.

There were a couple of those. As we worked on the framework consistently and as we used it for our own work as we documented it thoroughly, it stayed while most of the others vanished their way. My interpretation is that one of the key popularity of the open-source project is being constant and having strong leadership. Symfony has that with the founder of Sensio Labs, a former schoolmate of mine, Fabien Potencier. He has an extraordinary vision about what is needed, what trade-offs you can do, and where you have to focus your energy. That's a thought fine alchemy, I'd say.

One of the key factors to the popularity of an open-source project is having strong leadership.

Going back to the admin tools, we decided to use Django and Django Rest framework when we started the project, mainly because it meant we were going to be able to write less code to get this CRUD API off the ground. One of the things that I love about Django, which we still use from time to time, is the free admin platform you get with it.

It can do that partly because it's a batter included framework that has everything available contextually to it to create those screens. React is very different in that regard in terms of there is these conceptual ideas of entity models and things like that. You said that was the fourth one you built. What were the other three?

The first one was for Symfony. It was directly inspired by Django Admin. Symfony has an admin generator and the idea was to generate an admin based on your existing model and a set of YAML files. It was super popular. Usually, developers don't want to spend time on admins because it's not customer-facing and user-facing. The customer doesn't want to pay a large sum of money for it. The first one was with Symfony, then I took the leadership of a PHP ORM called Propel. I built the revision of the admin generator of Symfony for Proper. We built the Angular ng-admin version and then the React Admin Framework. We're also currently working on a version for Solid and Svelte as an exploration of how it would feel like.

I get your point about “being close to the model makes it natural for an admin,” but we found that the way we built web applications is not like that anymore. The backend code is mostly reduced to not very much. When we build new web applications, we start with the front end because we use a centric approach and then we try to understand which type of data structure we need to support that user experience. We then create database and tables in a database. We need a way to present that data to the application. That's a solved problem now. You can press a button and have a working CRUD API based on a relational API.

We use tools like Postgres, Supabase, and stuff like that that give us API for free. Essentially, we spent zero time on doing CRUD because that would be time lost. Once we have a CRUD API, then we can only focus on the user experience. React is a very natural tool for that because it's XML. When I say that to people discovering React, they say, “I disagree. I think React is a very declarative way of explaining what you want to have in the end. You are using JSX for that, which reads XML.” With the Symfony generator, we were using YAML, which is a terrible language, in my opinion.

Before this episode, I was resting with a GitHub action and tend to agree. Maybe it's not the least worst, but I certainly don't enjoy opening YAML files in my editor.

XML is okay. It's expressive. It can be validated by Schema. It's fast. There are tons and tons of tools that allow you to use it and it uses web JavaScript. It gives this super-expressive and declarative language that is React and that lets you build web experiences in no time. You think about what you want and you show it. For instance, an admin. What is it? It's a data grid with columns and also a form with inputs, or that's what you write with React Admin. You say, “I want a data grid. You list the columns and I want to form you list the inputs,” and you have exactly what you want. If you need to tweak that and add conditionals to put some code in, you have the full power of JavaScript and React to do so.

React is a breakthrough in programming languages because it brings back declarativeness. It is a word with declarivity to software programmers who were mostly using imperative programming and then were struggling to translate a user experience into code. With React, it becomes much more natural. If you imagine a user experience, React makes it easy to write in a declarative way, and then you interface with the free CRUD API and then you have an admin. It's natural, fast, and enjoyable, and it has one extraordinary super work in this approach, which is composition. That's, I think, the greatest breakthrough of React. You build components and you can put components inside other components and separate responsibilities like that.

‍

It means you can get rid of a ton of concepts of software programming that you no longer need, like injection and object-oriented programming. All this stuff is not necessary anymore once you can separate components and compose them. I find it fast, natural, and scalable as well because some concepts and programming models are very interesting at first, but once you start getting more and more screens and user interactions, it becomes hell. YAML, in that respect, isn't the best developer experience, in my experience. Annotations are also hard to scale a thing because you end up with more annotations than code anyway that's personal.

It's interesting because I was never a front-end engineer, but I remember back when my agency was struggling to write single-page applications using Backbone, which was the tool that everyone seemed to be using at that time. I remember pretty much every project we built. They'd always get to a stage where the whole thing was unmaintainable. You fix a bug in one end and then out pops another bug. One of the things that I never taught is it has become much more of a concept now is this difference between imperativeness and declarative-ness. That becomes, in the same way, like with Kubernetes, for example.

That difference in approach has become more and more important over time. Reacts definitely show how we can build huge applications on mobile that are very complicated and much more robust. The code is way more robust and easier to work with. I'm curious to know, did you have a strategy around the open-source project with your agency that presume pays you a salary and put a roof over your head with your team? How did you figure out that balance of where to spend time? Does it in terms of generating revenue for a tool like this that you and I wouldn't necessarily think has an obvious path to doing that?

It's a moving target. First, I'd say it's a matter of philosophy. It's a set of core values. My company open-sources lots and lots of the work we do. If we sum up all the open-source libraries we've worked on, we have something like 70,000 stars in total for a company of about 20 people with no external funding. We have this sharing core value, which we strongly believe in. We don't think that having a proprietary code or secrecy of a U-code will bring us a competitive advantage. On the contrary, we benefit a lot from the open-source ecosystem and it feels natural to give back. The first thing is that originally, we didn't even think there would be a business model around it. Secondly, this is natural for an agency like ours because it allows us to showcase our expertise.

It allows us to appeal to new developers and customers because they see what we do and help us work without a single salesperson for a couple of years. It was a great way of producing content and giving it for free. It brings back business. It doesn't scale. Once you reach a few dozen people, you have to chase work like everybody else. For a small company like we were back then, it used to work. When an open-source library becomes popular, it becomes a cost and that's when the problems arise. With React Admin, we now have more than 20,000 stars. On GitHub, We have 3,000 new applications per month that launch using React Admin in the world. We have continuous new issues on the GitHub registry, like feature requests, etc.

This requires at least 1% or 2% full-time to maintain it. When dependencies release new versions, we need to update our code. You have work to do all the time. The more people come triaging issues, it takes a lot of time. A few years ago, we thought, “How can we not lose money with that?” We want to continue giving it away because that's something we love. We can decide on the roadmap. We can try what we want and it's liberating, but if it costs too much, then we will have to abandon it. I went to see other popular open-source maintainers and ask them how they did.

I went back to Symfony and Fabien Potencier and the people in France also working on open-source and they said, “You can sell trainings, certifications, or mugs. You can also do conferences, but this is not a very high margin.” Most people said, “If you are close enough to the business, then you can ask people to pay for it.” Close enough to business is important because if your open-source library is a very low-level library, like something that reads the file system and translates it into database, it's very far from the business.

React Admin is much closer to the business because you listen to what the end user wants and you can write React Admin code right away. The idea was we could ask people to pay for it. The most common business model for that is OpenCore. Having an open-source core, adding a layer of enterprise modules, and selling it with a subscription. That's what we did a few years ago. We worked on additional modules and Storefront to sell it, etc. It took us a bit of time and investment. A few years ago, we started it and we had a few subscribers like people who were waiting for a way to give us back. That was a great way of asking them to pay for it. We also sold support with it.

‍

Did you know that there was that pent-up demand there? Did they come to you and say, “We want to give you money before that,” or not?

A few people, but it's not representative. It's hard to do market analysis on open-source users because they're so diverse. Most of them are also lying when you say, “Would you pay for that?” “Sure, totally,” but they don't. It was a test for us, but surprisingly it worked because we had 5, 6, or 7 new subscribers every month, and these subscribers would not leave right away. They would stay for a few months. The business model that we have is that the companies have to pay the subscription for the duration of the development, not after they get to production. If a project needs five months of development, then they pay for five months.

Little by little, the number of active subscribers increased and people left, but we had a limited churn. A few years after that, we have more than 500 customers who want to subscribed to the offering. It's enough to fund an entire team to work full-time on React Admin open-source and enterprise edition. For me, it's a dream come true. We are funded by our customers to work on what we truly love and it's become an important part of our business. Twenty-five percent of our revenue we're mostly from service companies. The open-source revenue is about 25% of the total revenue.

In terms of the contributions or the commits to the repository, is the majority of the code going into the project folk who work with you, or is it mainly community provided or is it a mix?

It depends on which parts of the code you are looking at. The documentation is mostly us. You would probably expect it. Developers are not so keen on writing documentation. It's important and I like it. We write 99% of the documentation. As for the code, I'd say that many small features come from the community and we contribute the large features. It's also because when an external contributor suggests a large feature or a large change set, we know that it's also a large cost that they're handing out to us because we will have to maintain that code.

If we don't have the whys in-house and if we’re not sure about whether it's going to be used or not, we might be reluctant to accept large pool requests. It's a matter of economics because when someone opens a pool request, he's basically saying, “I'm giving that for free, but then you will have to maintain it for years afterwards. Good luck.” We have limited resources. If you look that there are more than 500 contributors to React Admin, from one-liners to very complicated features, the most active contributors to the project are people who work for us and who work full-time on the project.

‍

How do you go about managing that community and maintaining that community? Are there tools, processes, or techniques that you've found that have been effective?

I'd like to first say that we are not very good at it. We're mostly software engineers and we know coding pretty well. As for marketing, communication content, and community management, we are learning. What we're doing is that every answer to a question by the community is done by a core team member or someone with very strong expertise, which is very expensive. Usually, community management, support, or triage is done by people who you pay less. They don't need need to know the entire library because it's very time intensive and it might be a shame to lose that time. We feel that it gives us a strong connection to the community and we don't want the core team to be disconnected from actual needs.

We do everything ourselves. That's the first thing then we're using GitHub to do the support for the open-source framework. We're using Zendesk to do support the enterprise version. We're basically doing all the things by hand if we need some content. We think what would be cool and what would be a good way to learn this part of the framework. We think we can do a help desk application that has real-time notification, etc. and we go and build it and rerelease it. I'd say at the beginning, I was hoping that we could work based on signals back from the community telling us where we should go, but this signal is not strong and it's often misleading in my experience. It truly nails down to having a strong vision and knowing why you want to spend your time.

We've hired specialist people in sales and marketing to help us animate social networks, etc., which is also time-consuming. So far, it's working okay. We try to differentiate from many other companies based on open-source, who bet a lot on marketing because they're looking for growth. Not tons of these companies say, “Have one thing that is moderately successful.” We invest large sums of money into marketing and we get a huge user base. We're not interested in having a huge user base, which is interesting in having profitability. We already have it, so we have reached our goal.

In terms of the other projects you are working on, is GreenFrame what you're spending most of your time on now?

It's a great opportunity to talk about it. As a company and an entrepreneur, I'm very concerned with global warming and the impact that my actions have on global warming at a personal and professional level. The digital world is responsible for occurring to different estimations between 3% and 4% of the global CO2 equivalent emissions. Where does that come from? It's hard to say. There's no consensus in the scientific community. For most of it, there's no tool to measure the emissions of a website, a web application, etc. Rather, there are tools, but there are so simplistic or basic that they are unusable. We wanted to know how the apps we built for our own customers contributed to these carbon emissions. We looked for tools, but we found none.

The digital world is responsible for creating between 3% and 4% of the global CO₂ emissions.

We thought, “We're software engineers. We can build it. It cannot be that hard.” It’s a classic mistake. It was so hard and it took us two years to do it. We worked with the French University here. Nancy, a computer scientist, built a synthetic model of the emissions of the entire system that involves a web request when you go to an eCommerce website and browse the catalog and add a product to your cart and do checkout. There are tons of different equipment and software that are implied in this scenario, from the screen, the browser, your home network, the data center storage, etc. We needed a synthetic way to model that.

We also need tons of engineering to collect the signal from these different parts of the system, which is impossible to do in production because you would need to put a root program into everyone's terminal device to get their consumption. We fund another way by doing that in a lab or a controlled environment to rebuild the entire infrastructure. It took us two years and then we launched a tool called GreenFrame.io, which allows everyone to estimate the carbon emissions linked to user scenarios on a web application. We use it for our own needs. The core of GreenFrame is open-source. That's our value. You have a client carbon line application that allows you to measure a scenario from the CI workflow that you are running at every build.

We operate a service called GreenFrame.io that is subscription based that allows you to follow this for a long time, have it with zero installation because we run the analysis on our server, and have a deeper understanding of where the emissions come from and start a true carbon reduction strategy. We launched that service in October 2021. It's not as successful as GreenFrame because the maturity of our profession regarding carbon emissions is still pretty low. Many people want to do stuff, but they have so many more things to do, like the most optimized for performance, security, and maintainability. We're adding a new dimension and we're saying, “In addition to that, you have to optimize for carbon emissions.”

They have bigger fish to fry most of the time. I know that sooner or later, they won't have a choice. For GDPR, a law will pass that will force everyone in the digital sector to measure and reduce their emissions, like what happens for the car sector. It's natural because we are already emitting more than aviation and planes. There will be a time when these laws will pass. In France, the law is already forcing some actors in the digital sectors to measure their emissions. At the European level, the law is in preparation for 2025. my understanding is that, like for GDPR, everyone will look away until it's obligatory and compulsory, and then they will rush to implement it.

We're basically waiting for that moment to continue the development. I don't want to invest too much right now because I've seen all the companies in that sector that struggle to make a living. It's no longer possible to burn out investor money for years until you get profitability. What we're targeting is profitability. It's a pet project for now. We've invested a lot in it. It works, it's in production, and it has customers, but we'll probably wait a bit to invest more to make sure that the market is receptive and ready to follow us.

It's no longer possible to burn out investor money for years until you get profitability.

I do remember my email inbox the week that the GDPR law came into force. It was hundreds and hundreds of emails from 25 years of putting your email address into a form somewhere. I'll never forget those times. It is interesting. In terms of the big cloud providers like the big three, where do they sit in terms of progressiveness on this? You're right. The industry as a whole. The two things that people care about are price and performance. One of the things is that it's not a dimension that people or the providers themselves sell on where the energy comes from or if you host in Frankfurt AWS. Is that better or worse than hosting in London or Mumbai?

They are forced to do carbon accounting by their customers because the large corporate companies, at least in France, I don't know how it is abroad, must provide once a year a report where they shoot with their stakeholders how much carbon damage that year and data center emissions must be accounted for. Large corporate companies ask their cloud providers for this information. Their cloud providers or the large big three cloud providers, have all replied with the calculator, which is answering the question. It's a merit. I'd say with nuance, it’s missing the point to get a bit into more details. If you listen at Microsoft, for instance, they advertise a carbon-negative data center where they say, “You can run servers and this will pump out carbon from the atmosphere.”

Is that possible? It is not. There are ways to pump out carbon from the atmosphere. It's called Direct Air Capture. It was so expensive. It consumes electricity produced with fossil fuels, etc. There's a lot of greenwash on this subject. The problem is that it's possible because the problem is complex. It's hard to have third-party certification on these claims. There are no international norms. There is no way to put everyone on the same page regarding that.

For having tried some of these calculators, for instance, I have tried the Amazon web service carbon calculator, it doesn't show anything under a ton of carbon emissions. Last time I checked, I had an invoice of about €1,500 per month at Amazon and my carbon emissions were nil. It's under the detection threshold.

That means it's okay for very large companies, but for everyone else, you have to find another way. The most important thing that we discovered with GreenFrame by measuring the emissions from the entire stack is that if you add the servers or the database to reverse proxies the application servers, etc., all that accounts for less than 5% of the total emissions of the execution of a web scenario. The rest is the network and the client. Most people focus on optimizing data center emissions. They're already optimized because we optimize the costs.

If you think about it, when you execute, let's say, one web request, one server is optimized to respond to web requests thousands of times per second. The marginal cost of one additional request is almost no. There is no linearity in the electricity consumption and therefore covered emissions of networks. If you have a large tube, whether you put one byte, one megabyte, or one gigabyte in this tube, it doesn't matter.

In the laptop you're using, you do one thing at a time and this one thing consumes the entire electricity of your laptop. You're probably consuming between 20 and 30 Watts and it's affected one task recording of this show. The server from Zoom that we're using is treating thousand and thousand of emission at the same time. It has a marginal cost.

My instinctive thought would be the other way around. In Flagsmith, we're serving thousands of requests a second. We have an AWS bigger than yours, but not by a huge amount. We were serving billions of requests a month and we've optimized the hell out of that and performance. That's interesting as well because in terms of if you measure something and then you're like, “What actions can I take to reduce that?” what you're saying is that from the engineering side, there's not a great deal that you can do. Is that fit?

There is a great deal that you can do, but most of the benefits come before engineering. They come from the design phase. If you design a website with a very large video that is on autoplay as soon as you get on the webpage and you can put the best engineer to optimize that, they will never get away with it. The first one is to think about it at the design phase and get rid of all the features, content, and the bells and whistles that you don't need.

You have to target very old devices. You have to test your websites on your grandma's desktop computer that she spends hours getting her tax reports on. You have to use this kind of device when you are on a web agency because these are the devices that people will have to change if your website doesn't run on it. That's the actions with the biggest benefits.

On the engineering side, there are many, many “best practices” of ecodesign, especially in France, which is quite advanced in the topic. We have something 4 or 5 different guides of good practices that are edited. Most of them come from web performance or from public wisdom about how to optimize a web server. Those are not tested and not scientifically verified.

You need a tool to test before and after in a consistent way. That's where GreenFrame comes in because we can do it in an iterative way. We can test one practice, dismiss it if it doesn't have a positive effect, test another, etc. Little by little, we can get a significant gain. To give you an example, we worked with the French newspaper, Le Monde. It’s one of the leading daily newspapers in France and they asked us to help them reduce the emissions of a visit to the homepage by 30%.

‍

We worked for two months and did a lot of small tweaks. After these two months, we told them, “We managed to reduce the emissions by 21% and if you remove advertising and third-party tax, it's 70%.”  They said, “We'll keep 21%. It is good.” That's what we got to. It's possible, but the limit of the engineering is the actual business and user experience.

It's interesting because I'm involved with another business that sells things online and we've spent a huge amount of effort optimizing for things like time to first ping, the performance, and trying to get people to check out as efficiently as possible. What you're saying is the side benefit of that. If you streamlined your applications to try and achieve that, you are getting an energy benefit at the same time.

Supposedly, you are lowering the energy cost and, therefore, the carbon emission cost of one user scenario, butn another question arises. If the user doesn't take 2 or 3 minutes to achieve one scenario, but one minute, what will they do with the additional time? Will they close their electronic device or will they do more on another website? This is called The Rebound Effect. It's very common in environmental analysis and it's something that tells us that even by optimizing our emissions, we might not lower the total amount of carbon emissions.

It’s because if it gets cheaper, people will do it more and the net effect might be an increase. I don't have a solution to that. I think the law will be the only solution to that by limiting what people can do like for cars. People can buy very powerful cars, but they have to put in twice the cost. Somehow it limits the usage of these devices.

It's been fascinating talking to you and I'm impressed with where you've got to. What's next for GreenFrame, then?

Ideally, we have tons of ideas about it, like how to first help the general audience understand the concepts. One good way would be a tag that website can put on every page. That helps us measure the carbon emissions of a visit to that page. They can put that tag on the footer and say, “You visited this page. This emitted 40 milligrams of CO2.” We then give a label A, B, C, D, E, etc. This is something that is possible. I'm not sure if this is the right direction because this somehow gives the responsibility for carbon emissions to the consumers. My opinion is that it's mostly the responsibility of the manufacturers or the people who make electronic devices or software.

We are responsible for that because you cannot blindly say, “I have done something that is so emmitive that it has a huge carbon footprint, but I don't use it, so it's not my responsibility.” It's our responsibility to do it. I'd love that GreenFrame also became something that every new web project adds to their CI workflow for a unit test or performance test. We already have a GitHub action for that and we're working to make it even easier. I'd love for people to learn the good practices of eco-design at school.

We're also working with universities here in France to help them change the way they teach Computer Science and Programming to emphasize the carbon consequences. There are tons of things that we want to do, but we need investors and someone to give us a push to move forward because the market isn't ready yet to make it a profitable way. We need some investment. We've already invested quite a lot ourselves, so we'll be looking for more investors to help us move forward with GreenFrame.

‍

Good luck with the project. Thank you for all your resource work in the past. It's been great to chat.

Thank you very much, Ben. It's been a pleasure to chat with you. I’m looking forward to having more discussions in the future.

Thanks, Francois.

Important Links

• React Admin
• Marmelab
• Postgres
• Supabase
• Backbone
• GreenFrame.io