How long have you been reading?
Somehow, "The Mythical Man-Month", "Bear and Waltz", or "Extreme Programming (White)" Book) ”, I personally feel that it is one of the classic reading materials in programming.
However, I have read all the three books I have posted, but in fact, the cathedral and the bazaar passed by.
The reason is that this is a book developed about OSS software, especially the development model of Linux. At that time, when I was reading and fishing for such classic reading materials, it wasn't a very interesting subject. Because I was writing proprietary and on-premise software exclusively.
I felt a coat color that was quite different from "The Mythical Man-Month" that criticized the easy recruitment, "Kuma to Waltz" that taught me about risk management, and "Extreme Programming" that felt the hot sprout of agile development. right.
Amazon's book introduction page also says "a must-read book for Linux and open source (OSS) people", and of course I think that's correct, but ** I think it's easy to narrow the readers too much. That's right **. [^ 1]
In particular, it is a book that shows how software development should be in a world where everything is becoming more and more open.
I said it was a book, but it is a book that I wrote about OSS. The books and translations themselves are OSS under Creative Commons.
In fact, in addition to the above, the book version includes "Noosphere Reclaimed" and "[Magic Pot](https://cruel.org/freeware/magicpot. html) ”, and an interview by the translator Yamagata Sensei is also included in the set, but this time we will cover up to“ The Cathedral and the Bazaar ”. It's interesting enough so far, so if you haven't read it, please do. It is a very easy-to-read amount of about 40 pages in PDF.
If you know a little about the cathedral and the bazaar, or if you know the history of the battle between OSS and big companies (window companies, blue companies, red companies, etc.), "cathedral" is a big company manual. You might think of proprietary and closed development, and bazaar as free software development by OSS.
I want people who think so to read it. Because ** The Cathedral and the Bazaar are not metaphors for large corporations and OSS. ** **
Let's quote from the text. The cathedral is the following model.
But at a higher level, I also thought that there would be some inevitable complexity and that a more centralized and a priori approach would be needed. The most important software (OS and really large tools like Emacs) has to be assembled like a cathedral, and one wizard or a small group of wizards should assemble it completely isolated and carefully. I thought I had to release the beta version until it was completed.
Yes, ** Sangharama refers to a serial model ** that is premised on the early Big Design Upfront.
So what is a bazaar model?
I was totally surprised by the development style of Linus Tovals-released all the time, leaving whatever was left to me and opening up anything to the orgy.
A bazaar is an open and iterative development model that assumes frequent release cycles **.
In other words, in today's profane language (while fully aware that there is a sway as a definition),
-** Garan = Waterfall and Centralization ** -** Bazaar = Agile and self-organizing **
I think it can be said.
Of course, there are many cathedral models in large companies, and there are many bazaar models in OSS, but the cathedral and bazaar refer only to the development model, not the form of the project. What I want to say is that ** some bazaar elements can be applied even in closed development within a company **.
What is written in the cathedral and the bazaar is ** an analysis of "why the bazaar model works" **. And it's worth noting that this analysis was done in the 1990s.
Because, at that time, even Git didn't exist, let alone Github (Linus made Git just after this sentence was translated into Japanese). Of course there is no Slack either. There are only mailing lists and early WWW.
This is just an old tale for those who are familiar with modern Github, but what about your organization? ** Isn't the internal information sharing system actually stopped in the 1990s? ** Isn't there still a lot of people who mainly communicate by e-mail, and the source code is eventually uploaded to the shared file server, and even if there is only SVN?
Yes, even in such a situation, you can see from this book that the bazaar model works. This means, "If you are satisfied, any company can do it."
So why does the unordered bazaar model work, "I release it all the time, leave it to me, and open it up to orgy?"
There are many points in this book, but I personally think the following three are important.
-** Driven by the personal passion of the developer ** ――On the contrary, if you lose your passion, get off from the main -** Treat users as co-developers ** --Become an excellent beta tester, debugger and fixer -** Continue to attract user interest and passion ** --Frequent releases --Visualization of contribution
First and foremost, even though it is a bazaar model, it is the head of the bazaar, Linus in Linux and RMS in Emacs. It can be an individual or a team, but in any case there are people in the bazaar who are loosely determined (and trusted by everyone to do so). The project is driven by the person's personal passion.
And in the bazaar, users of the software and libraries are treated as co-developers. Of course, the condition would be that the user is also passionate about using the software.
And there are developers with passion, users with passion, and one more thing we need is a mechanism to keep passion on fire. This is backed by frequent releases, visualization of contributions, and more specifically, project transparency itself.
Passionate developers open their software, acquire enthusiastic users thanks to frequent releases and contributions, and the contributions of those enthusiastic users further develop the project.
In a very simple way, this flow is how the bazaar model works.
Given the above process, can we really bring it into the enterprise?
I personally think that I can do it. I think there is an approach called "in-house OSS" for some large companies and "partial OSS" for small and medium-sized companies.
Literally, it is to publish the source code to the company and promote the project. You can publish each project itself, but if it is difficult, you can think of the tools, libraries, IaC code, etc. used in that project. I think the important thing is not just to publish it, but to use it properly in our project and to give it some ownership by giving it repository ownership.
To tell and hear various stories, I think Google is the company that is doing this most actively. Of course, Google itself plays a fairly pioneering role in OSS, but more than that, Google is creating new products and OSS from its own tools.
Kubernetes, for example, is no longer the standard for container orchestration tools, but it must have originally been derived from Google's internal and closed tools. Kubernetes has become OSS as a result, but it seems that other tools that are on GCP are making good use of in-house tools and deploying them in products. Isn't this proof that the in-house bazaar model is working?
This is a method of keeping the core part proprietary without converting it to OSS, and converting the peripheral tools to OSS. Shiguredo is the one that comes to my head in this way. Shiguredo is closed and proprietary about its core product "WebRTC SFU Sora", but its peripheral tools are all OSS. [^ 2]
And regarding the OSS group, functions are being added while lively discussions are being made on the Discord server, and at the same time the development speed is maintained, the openness attracts developers, and probably the sales of Sora itself are also considerable. It seems that they are making a contribution.
In this way, it should be possible to incorporate the ** OSS aspect as a company and incorporate the merits of the bazaar method **.
However, I don't think this process works for any company. If “transparency” and “slack” are not ensured within the company, it will be difficult to develop it.
The first thing you need is transparency. In each project, it is very important to present a roadmap for the future as well as the current state of what technology is being made now.
Regardless of whether you publish it internally or externally, it will be difficult for you to use it in the first place unless you always appeal the technical transparency without strange concealment.
It's not a chat tool. It's here.
Whether inside or outside the company, these OSS activities are not possible if the operation is cut down 100%. Google's 20% rule is famous, but the bazaar model will not work unless you have the time to devote yourself to making products in the first place.
That's why I wrote it steadily. Personally, I still feel that I got a good perspective on how to develop the software of the company, so I wrote it briefly.
I think I'll read the classic again. It was a good book.
[^ 1]: I think it may be unwilling for people in the OSS area, and the development process that is not truly open and the OSS process are essentially completely different! I think there is also criticism. As an essence [^ 2]: Actually, Sora itself is quite OSS-like because of its high release frequency and open roadmap.
Recommended Posts