Presentation Week
Inkscape
It’s been the busiest week this semester for me. I had two projects to be done,
had to complete some paperwork for my status, had an interview, and on top of
them, I had a fever which could affect my graduation. Fortunately, it went away
(I believe) with some rest. Next week should be better and the following week I
have two finals. I hope everything goes okay. Although it was our presentation
week, I could not make any contributions, so I will have to depend on past
contributions for it. It’s my first time presenting online, and I am pretty
nervous about it. I know it cannot be an excuse and absolutely needs to be
fixed, but it has also been pretty tough presenting in English. Anyway, We had a
couple of meetings to create our slides, and discussed who is showing what. I
have been learning about Docker and Docker Overlay to improve
inkscape-ci-docker, which currently only has ci builds integrations to the
main inkscape repo and the extension repo. However, learning the concept of
overlay networks seems impossible to be done in a short-term, so I decided to
add it to my post-graduation todo list.
Thoughts on “Makers and Takers”
Writing this post took the longest since I am not familiar with most of the general business concept the author uses. However, I really enjoyed this post. It gave me an entirely new view of developing business using or creating open-source software. One of the things I like about open-source related reading is that it gives me not only information related software, but also general knowledge. For example, we learned game theory in Discrete Structures, but I never had a chance to come up with a practical application of it. The author applies this theory with defining two primary players in the open-source business world, which are Makers and Takers. Buytaert defines them as follows:
- Makers
- Companies who invests on maintaining, engineering their product as open-sour ce intentionally (ie. Red Hat)
- Takers
- Companies, from technology startups to technology giants, monetize Open Sour ce projects without contributing back (ie. Ama*on Web Service)
However, Makers can be Takers at the same time, and the relationships of companies can be beautifully applied to the Prisoners’ Dilemma. He gives an example with two random companies, both yielding to be Takers even though they know it’s better to collaborate for them. This is because they are rational enough to not avoid worst-case that one choose to contribute and the other not contribute. This is the worst for the first one, especially if the other is the competitor. Therefore, they will choose to not contribute, which results in making much less money than the best case. I liked how he linked it to a much familiar case. Say that people are sharing a room, and if everyone washes dishes every time, there won’t be a loss of clean plates to use, however, we always think “What if I wash and others don’t”. This example made the concept clearer.
Although I thought he is implying that Makers are the good, and Takers are the evil, and I even agreed it looks like the nature of the world, it is not his point at all. Instead, he later defines one of his company as a Taker.
He then brings up common goods and public goods to combine with his theory. He emphasizes how open-source is public goods (not-rivalrous). At the same time, open-source software can be a common good (rivalrous) for companies because it can prevent people from using similar products. This reminded me of the stupid war between users of Emacs and Vim (it’s an example, and I know more than half of them are just joking) because some users of Vim would never use Emacs and vice versa. I have never thought this way, and it is quite interesting. That said, he criticizes “Customer Free Riders,” which I believe is one of the most crucial points in this post because he doesn’t think “software free-riders” are a potential problem for the community. “Software free-riders” are users of the software who will never contribute back to it. He thinks that way because those “software free riders” can bring new users to the community, and if even a small amount of them contribute to the project, it is generally seen as successful. It made sense to me, but I don’t know if this is true or not because I have never owned a project or company.
He also emphasizes the history of common goods by referring a few studies that have proved the importance of external agents avoiding free riders. To be honest, I haven’t even heard of those studies. However, the introduction sentence by Mancur Olson is straight foreword. He says, “Unless the number of individuals is quite small, or unless there is coercion or some other special device to make individuals act in their common interest, rational, self-interested individuals will not act to achieve their common or group interest.” I think every one of us has experienced in activities which are not personal, such as his example of dishes in a shared kitchen. He concludes that centralization and privatization as a key for maintaining a project as the project gets larger.
Furthermore, he says there is the third idea to keep common goods, which is studied by Elinor Ostrom that introduced ways to manage commons, not either privatizing or centralizing. Though all the cases are shown by Ostrom eventually become closed access, it is still the community that maintains the resource. I felt this could be a great hint to manage to keep the “community.”
Having defined the terms above, he suggests three ways to scale and sustain open-source projects successfully.
- Appeal fairness
- Encouraging end-users to have selective benefits to Makers
- Experiment with new licenses
Though there are not many concepts that I was familiar with, the point he made is clear. I haven’t even categorized mozilla as an company, and firefox as its product before reading this post. I felt that this post is not about open-source should be, but rather, he suggests a practical approach to avoid open-source to be too philosophical. Also, I realized that there seems to be a lot of communities believing in “pure-open,” and many of them failed or having some difficulties. People involved in that might have doubts believing the idea of open source, I think this should be avoided for the feature of the communities. As I said in the last post, I think it is essential to respect the idea of open-source in general. I also learned that several approaches tend to be criticized, but the creators don’t necessarily intend to break the system of open source.