Forking out of an open-source conflict
Prologue
I’ve been working as a freelance developer for almost two years now. During that time, I got to work with full-stack JavaScript solutions involving MongoDB, Node.js and AngularJS. About a year ago I noticed a recurring pattern while creating new web applications, and I realized that the last three web applications I’ve worked on are all using the same technologies: MongoDB as the Database, Node.js & Express as the backend framework, and AngularJS as the front-end framework. I started building a boilerplate to help me jumpstart these kind of projects, and was wondering if anyone else was noticing the same pattern. A quick googling discovered a mongodb blog post by Valeri Karpov suggesting the name MEAN. As far as I can tell this is the first time anybody mentioned the MEAN stack by its name.
About 10 months ago I received a new project from a company named Linnovate. The project was a messed up variant of MEAN that Linnovate had inherited from another company. They had asked me if I could try and organize it. Luckily, I already had my boilerplate ready, so I showed it to them, and together we decided to open-source it. Not too long after, the community started to react to the boilerplate. A post on hacker news got us the first traction, then some people started tweeting about it, and soon enough, blog posts were written about the different aspects of the stack. MEAN began gaining momentum.
Meanwhile on Github, I had one of the best experiences of my professional career. As project maintainer I discovered the real power of open-source. A community of vigorous developers that helped me learn many new things I wouldn’t be able to learn anywhere else: From niche pitfalls to big version changes, through project management and community etiquette, all of which with passion for better coding. I became more and more involved, checking my emails more frequently than ever, constantly tweaking with the issues page, testing pull requests branches and more, until it had grown to fill the better part of my daily routine.
Conflict
Everything was going smoothly up until the end of last year. The deal was that I will be the chief maintainer of the project while Linnovate will sponsor some of my time. That was a great deal, because it allowed Linnovate to help the community without hurting its core business, and for me to stay independent while keeping the project well maintained. The only problem is that companies and freelance developers obviously have different agendas. So, towards the end of last year, this shift in preferences put our collaboration in a crossroad.
In almost any other professional field this could easily become a serious legal problem, generally extremely counterproductive to the interests of both sides. Luckily in our open-source community, there is a more elegant solution, forking out of the conflict. So about a month ago, I left MEAN.IO to form a new project named MEAN.JS. I called my friend and colleague Roie Cohen who was also the first MEAN contributor and together we got to work.
Denouement
When we approached the development of MEAN.JS we had a major design goal in mind: Evolving MEAN.JS from an hackathon boilerplate to a real production framework. In other words - we wanted to help convince your PM that its time to leave PHP. Since each of the MEAN components is production-ready, the problem remains to properly combine them together, and with this in mind, we attacked a few problems:
Modularity
In order for MEAN.JS to become better we needed to break it into different clear modules, each supporting a main core feature. We also needed to rearrange the project in a way that allows the creation of new logical modules. So, we changed the project structure a bit to support this new approach, some files were split, some consolidated, but in the end we did two major things:
We changed the backend structure to support MVC modules.
We restructured the AngularJS part to support vertical modules.
We also added some autoloading of modules features to ease the development process. Better modularity by itself is great, but it also helped us solve another major issue with the original MEAN, legacy support.
Legacy Support
One of the problems of the original MEAN stack was its poor legacy support. The project changed constantly with no version scheme marking the different versions. Many features were added or removed without the proper notice, people had problems updating their project, and it was generally time to put down some rules. So we borrowed from other frameworks we liked:
Version Numbers - Like other frameworks the version number will be broken to odd and even numbers, where even version numbers indicate stable releases.
Branching - Instead of merging changes directly to the master branch, we’ll use tags and branches in order to properly mark the different changes and patches.
Modularity - Breaking the project into more pieces gave us the ability to commit bug patches more easily.
Our desire to support a larger audience, while still include the original MEAN community, led us to deal with the next major complaint of MEAN users, Documentation.
Documentation
Maybe the most common request of our community, a proper documentation is a must-have for any respectable project. We approached this by creating a new website for the stack that includes a basic documentation of how the boilerplate is built, what are the major dependencies and how to configure them, how the MEAN.JS design works, and how to get started with the development of your new application. You can visit the documentation page to find out more, but if you still have questions, you can now directly ask the community.
Community
The last piece of the puzzle was how to offer better support to MEAN developers. After trying few experimental tools, we decided it would be better to use the already established communication channels. We have new twitter account and a facebook page for news updates and other discussions, the MEAN.JS google group for technical support, and the #meanjs IRC channel for real-time support. So please contact us if you have any further questions.
The Future
Regarding the future development, we decided on concentrating our efforts in four areas:
Core - Improving the MEAN core and fixing bugs.
Modules - Building companion modules to extend MEAN with different web application features.
Generator - We already started building the long awaited yeoman generator, which we plan to release in the next couple of weeks.
Admin - Creating an admin panel for managing your MEAN application.
Epilogue
Leaving the original MEAN.IO project was one of hardest turning points of my career, but sometimes you have to take a risk in favour of the values you believe in. Having said that, it has set us free to develop MEAN the way we want it to be. Today we present to you the first version of MEAN.JS and asking you to join us on this new journey.
Amos Haviv
MEAN Author.
* Please feel free to ask me anything, I will do my best to provide you with solid facts and honest opinion.
