Hey, I touched that problem in one of my blog posts about two months ago The question is whether we keep everything all the source code in one large repository or we break it down into small parts. And there are so many articles about that even conference speeches where people are suggesting that It’s better to keep everything in one large repository no matter how big it is and for many reasons, for example, they say that it’s easier for delivery, for packaging the whole thing and delivering to production, also they’re saying it is better for making changes because everything stays in one large namespace, in one large directory and subdirectories where you can you know you change files here, and they are interconnected to each other, you don’t have any external dependencies everything is connected inside and when you want to release and make changes and release then we just make changes, package the whole thing together and deploy. Continuous integration is easier. That’s what they’re saying because everything is in one place again, no external dependencies. It’s just easier and they keep it all together Even, you know, I found many articles for that by big guys like Google, including Facebook and others Which are saying that we decided to move to that direction we decided to you know, to keep everything in one place because it’s better for this and that I totally disagree with that. I think that approach is similar to saying that it’s better to have one large class with many methods inside because it’s easier for maintainability, it’s easier for delivery, it’s easier for making changes because look, it’s a large class, all the metas stay together we don’t need to go from class to class, from file to file. We just make changes here and that’s it That’s ridiculous I think. That’s just I understand the reasoning behind that saying but their business is just wrong because it’s a path to completely unattainable code because if you keep all the pieces together it may look more maintainable for you while you’re working with that but in the future the more changes you make, the more people get into that project, the more developers are interested in actually making modifications to that code the more difficult will be for them. In Zerocracy, in our team and I think you should do the same We practice the completely opposite approach, we think that the repositories have to be not only as small as possible, but focused on one single technology So if it is Java language, then it’s repository for a Java language. If for example in your project you have something in Java, something in Java Script, something in Ruby and then something in XML, for example then it’s better to split that into four different pieces and configure four different algorithms, four different procedures for delivering that stuff, for testing that stuff, for continuous integration there So, for each technology we absolutely need to have one single repository. So there are no mixes of technologies inside repository So we never have like one github repo for the Java inside and also the Java Script, and it also helps us for management because we have sort of flat teams where everybody can get the next task no matter what are the qualifications of that person So if there is the programmer, for Zerocracy, for Zerocrat, for our chat bot it doesn’t matter what that person is professional in, if the developer is in the project, then randomly That developer will get the tasks from zerocrat So that’s why we need single technology in each repository And I can see why those big companies like Google and Facebook go in for the monolithic repository because I’m not gonna say stupid but I think their programmers are just lazy to configure everything correctly because it is more difficult, it is more complex. It will take way more time to break down large pieces into small ones and then configure individual routines for packaging, delivering, testing and everything. Of course, it’s easier to put everything in one place and just ask one group of people or one guy to configure everything, make sure everything, all the tests pass and make sure the continuous integration is done right and that’s it. And then it’s called a day. In my blog post, you check it out, I demonstrated an example of how I took a large piece of code, a large repository and then extracted a smaller piece out of it and made even an Standalone open-source component, which that bigger repository is using now as an external dependency and you can see how much time it took for me. There’s the question of just maybe I don’t know, like a 50 lines of code, but I’ve spent like maybe a day or so, maybe less for doing that, but what I achieved thanks to that what benefits I got is incomparable to the to the potential mass and maintainability issues, which I would have if I would keep that smaller piece inside a larger repository So my recommendation is no more lithic repos, the smaller you can, the better. Stay tuned.