This week, I got to do a really insightful reading about what makes open source successful in the first place: the Bazaar model. I also got to see how open source has basically been embraced by corporations and governments, though things do get tense over time for the former (because, of course the goals of corporations will never really be aligned with open source projects).

The Cathedral and the Bazaar

The Cathedral and the Bazaar follows through on an open source developer who ultimately ends up taking open source project as a result of trying to find a software that supported the email protocol he wanted to use and a specific functionality in the email protocol and learning a lot of valuable lessons about how his specific open source project operated. He wasn’t able to find any, so he started forked two open source projects to extend the functionality of the software to support the specific functionality that he wanted to have in the software.

(Note that I mentioned two: the writer discusses how he wished to contribute to a software that supported multiple email protocols, something the first forked open source project didn’t support, so he had to fork another open source email client.)

But long story short, after the author contributed to the second open source email client, he was told by the former maintainer of that client that the former maintainer had lost interest in maintaining the project, and that it would be better for the project health if the writer took over maintaining the project, and he learned that what made his open source project great: the people who also supported the goals of his open source project, and the (sometimes conflicting but better) ideas that came along with them, or basically a bazaar model where people are free to contribute their ideas in and modify old ones.

There were a few things that I could relate to the story, especially this one:

“Plan to throw one away; you will, anyhow.” (Fred Brooks, The Mythical Man-Month, Chapter 11)

Why would I relate to this? This is kind of twofold. Our professor, Johanna, did discuss how there have been teams in the past who had worked on creating a pull request to an issue, only to have it be kind of thrown out for whatever reason. And Stella and I have been attacking our open source project, OpenFoodFact’s new mobile app, in this way too. At first, we actually claimed the issues that we wanted to fix (as in we would request to work on the issue, and then wait to get assigned). But later on, we just started taking on issues after we requested to work on the issue, since the maintainers sometimes took a bit to respond to our requests. We did these fixes under the expectation that maybe they already have a fix (which good on them, but it’s good Dart and Flutter practice, which we also wanted to do since neither of us had that much experience in those fields).

Namely, we claimed an issue where iOS users weren’t able to switch between different text fields like on Android. We proposed just having a Flutter based solution of implementing this, since I have a philosophy of not waiting on the underlying framework to implement it and just implement it in any way that we could. However, this one guy didn’t like our idea, as they would rather keep the code as the same as possible across all the platforms and would rather wait on the Flutter framework to implement the feature. We only found out about this after I had started searching up solutions to this problem, which was a bummer since we wanted to get another patch out (but instead, we get to talk about the different personalities of the project) and we had to throw all our efforts away. Oh well.

But there was also another thing that related to us pretty well:

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

This was one of those issues where there is a pretty active community when it comes to people finding out use cases that are not covered already by the app, and seeing weird bugs pop up. Then there are people like me who are willing to take their time and dig down into the code to see what went wrong. Maybe way too many of them because I might have to start proposing new ideas to add.

However, weirdly enough, the vibes of the open source project we are working on feels a bit more like a cathedral, or a project where it’s mostly the maintainers leading the way, providing little to no opportunity for us to suggest new ideas (which usually happens in corporations). I haven’t been able to join the open source project’s Google Hangouts calls, but maybe I’ll do that next week and hopefully make the vibes of the project feel more like what happened in The Cathedral and the Bazaar.

The Coffeehouse

Nowadays, a third model has sprung up, merging the informalness, decentralized situation of the bazaar model and the constrained formalness of the cathedral model, called the coffeehouse model. This model, popularized by Claude Warren, is basically kind of like a third place of sorts (somewhere that isn’t home or work) where people can freely talk about open source ideas and projects and new tech going on, without any of the financial or project goal constraints in mind that you might see in a cathedral model (or borderline the bazaar model; though the main worry of a bazaar model is a place where maybe your voice gets lost in the marketplace). There will always be people popping in and out of different coffeehouses (eg different social media platforms or even different tech conferences), and there will be some who visit this coffeehouse more often than other people.

One such people who would probably visit this coffeehouse are people who work at open source program offices for tech corporations, like Microsoft, and open source program offices for governments, such as the Paris city government. Both companies employ these open source program office to use open source software as a cheaper and faster way of creating software that they would otherwise duplicate.

However, Microsoft has financial intent on this, while the Paris city government has good policy intent on this. By focusing more money and resources on extending functionality of existing open source software, it also becomes a PR win for companies like Microsoft, as they are seen less as money greedy people and more as supporters of open source. However, as Warren discussed in his coffeehouse talk, there is a bit of red tape involved with open source projects, as there are still open questions like:

• What if someone abandons their project, or worse, decides to nuke their project for whatever reason (such as feeling like their open source project was just being used as free labor)?
  • Are we the victim of a chain reaction from this activity?
• What licenses are the projects using?
  • Are they compatible?
• How do we not accidentally leak too much of our “secret sauce”?
• Who do we look for help when something goes wrong?

An open source program office can answer these questions.

For governments like Paris’ city government, there’s a social aspect to creating and contributing to open source projects–they argue that if it’s public money, it should be free and open to the public to be used. In addition, the open source projects that city governments get to create can also allow people to participate in a democracy, by allowing them to get pretty involved in fixing city government services (though no amount of code will ever fix stupid people running the services). I personally think that this level of political environment is cool, as it’s way more accessible than canvassing through streets (particularly differently-abled people or people who have really bad transit options to even engage in such activities) or doing some other physical work.

I do have to wonder though–ultimately, how stable will this relationship between open source software and the corporate world will be? I kind of hinted at how people have nuked their project before, and I would not be surprised if this happens again. I kind of wonder if the better thing to do than to pay people to contribute to open source software on company time is to actually pay the existing developers first, as like a thank you for developing the software (as long as the developers are fine).