The brilliance and poverty of the open source RawCMS platform. Reasons for failure and conclusions

I love open source software. I started developing an open source side project in 2006 and that was the secret of my career. Thanks to my experiments at the time, I hope I have grown as a developer and give back to the Open Source community. In my opinion, open source is the growth driver for companies and developers. And today I want to talk about my experience, which began in 2018, working on an open source low-code platform called RawCMS.


RawCMS started as a side project to improve the future of core 3.1 and explore the possibility of working with unstructured data to speed up the development process.

During development, I ran into many problems and finally came up with a working proof of concept. The result was colossal, and I have to thank all its participants (and there are more than 20) many times.

We overcame all technical limitations and made the program work. Some of the topics were up-to-date, allowing me to participate in the most important European .Net conferences to share what we have learned.

Moreover, when we realized that without sponsorship and with too little community support, we had no opportunity to develop the project as a real product, we decided to archive the project. I began to think about what we had managed to do.

I believed and still believe that there were no gaps in the product definition. RawCMS aimed to do what a developer would really need in the future, but RawCMS was too hard to understand.

The resolution of all the complexity we faced along the way was great, but to fight the complexity we needed complexity. This made it difficult to initially understand the logic of the application and contribute to it.

All this complexity frightened the developers on the way.

This is probably why our interest in the project dried up and we abandoned it. It’s hard to donate your time to an open source project if it turns out to be painful.

At this point, before forgetting about the project, I wanted to think about what worked and what didn’t – in retrospect.

The final conclusion: we chose the worst technology for our needs.

To convince the person inside me who has given up the truth, I rethought project from the beginning. Using Symfony instead of .Net, it took me a little over two days to get started and got a working proof of concept. I haven’t implemented the whole set of functions, but I’m pretty sure that in the new circumstances we won’t find a lot of problems. It taught me a lot.

How could I do the same thing in two days as in two years?

The answer to this question scared me a lot, I was wondering where I went wrong. In the following sections, I will tell you what my mistakes were and how I could have done better.

The right tool

I am not late with .Net. I have been working with the platform since 2005, have implemented many large corporate projects, and have been invited to many conferences to share my experience.

But I just picked the wrong tool for a side project. I still think .Net is probably the best framework for enterprise applications, and C # is unmatched in terms of performance and development experience.

The problem was this: I chose .NET only because it was a framework in which I feel more confident. For me, choosing .Net was an opportunity for success. And I was wrong.

Since starting this project, I’ve had to deal with some features that .Net does not natively support; every single problem was a challenge. I’m talking about untyped data management (in particular, mapping and GraphQL), having a plug-in architecture and embedding a modular SPA into it.

By the way, when I tried to repeat the same thing with Symfony, I found that this functionality is already ready to use. Each of the features mentioned turned out to be a feature included in the framework, so I just needed to put everything together, and not invent something. My first mistake was choosing the wrong tool for the job.

To persist in error is from the evil one

Mistakes are from a person, but persistence in a mistake is from the evil one. Trying to make everything work, I learned this from my own experience. This was an important lesson for me. Surrendering in front of a huge problem is not always a sign of weakness, and sometimes, maybe, proof that you are smart. I did not stop at difficulties and defeated the beast, but then what?

The cost of the work, as well as the difficulty, was enormous, I mean a lot of time and effort wasted, except for the wonderful experience and expertise that allowed me to (virtually) travel the world and tell my story.

What do I understand? Together, we never had to give up in the face of a problem, but faced with the complexity of one-on-one …

Ask yourself, is the problem in the problem itself or in you?

Before coding, tell us how you see the product

The big problem that I faced on this project was that the threshold for entering the project was very high. This turned out to be very painful for me: I had to spend a lot of time helping contributors in setting up the working environment and in understanding and implementing the task.

The fact is that in most cases people didn’t know what they were doing. Most of the contributors were students of young developers and got lost in all this complexity.

They probably also couldn’t understand why they were being asked to make any changes. The end result is that I spent a lot of time introducing the project to budding contributors, completing only a few small tasks.

This would not have happened if the system was simpler and based on a popular framework like Symphony – with a community where developers could find answers to their questions.

So, thanks to this project, I learned how to share how I see the project and explain the purpose of the project well. Having contributors is great, but if they can’t help, the project will stay on your shoulders, and the only result of your work will be teaching people what they will soon give up.


I still enjoy contributing to the open source world. Thinking about the time wasted on RawCMS, I really don’t feel like it’s wasted at all.

If you think about the real results, then yes, it was a failure. I wasted a lot of time and I was left with only a half working project with no users. I didn’t make money, nobody thanked me for what I did. The situation seems like a game in which it is impossible to win, but I don’t think it is. I am still convinced of the value of open source.

And here’s what I’ve learned from this experience:

  • I learned a lot about modern technologies, which increases my value as a professional.

  • Has been invited to many international conferences to clarify what he has learned.

  • Helped novice developers to take the first step.

  • Met a lot of great people who, like me, believe in the spirit of open source.

  • Gave something back to the open source community.

Well, looking at all these intangible results, I’m really happy that I wasted two years of my free time on a failed project.

But valuable experience can be gained even easier, for example, by pumping yourself in development in the direction “C # developer”… On it you can not only improve your qualifications, but also communicate with experienced mentors who will clarify incomprehensible points.

find outhow to level up in other specialties or master them from scratch:

Other professions and courses

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *