Thoughts on “Makers and Takers” by Dries Buytaert

This week I read a blog post, “Balancing Makers and Takers to scale and sustain Open Source”, by Dries Buytaert. While I try to approach any new text as an objective reader, I could not help but feel immediately and irrevocably thrown off by this piece. The post opens with: “In many ways, Open Source has won. Most people know that Open Source provides better quality software, at a lower cost, without vendor lock-in.” Open source has won in many ways and most people know the advantages of open source??! For me this was the first of multiple times where I encountered a bold statement, which then had to be heavily qualified if not contradicted later on. On the one hand, as Vicky Brasseur argued, and I am inclined to agree, open source has certainly made great strides, but also has a long way to go; this article suggests forms of organization and governance that may contribute to such improvement but it is nonetheless a pushy start. On the other hand, as Buytaert himself states not long thereafter, “proprietary software dominates most facets of our lives”. This is exactly because most people put very little thought in their software selections at all: to the extent that they do, most are still likely to feel more comfortable purchasing software from a major company, not peruse the options of small open source community productions. Thus while I do agree with the idea that open source “might be the only way to solve some of the world’s most important problems” (such as getting voting technology right) and helping pave the way for open source business to succeed is important for the future of open source, I couldn’t shake the feeling after this beginning that the post took a very limited view of the issues at stake and that I couldn’t quite nail down for whom this article was intended.

To be fair, the first “disclaimer” of the article acknowledges that open source becoming more diverse takes priority, and the second disclaimer did note that his suggestions were primarily aimed at “communities that operate with some level of commercial sponsorship, or communities that struggle with issues of long-term sustainability”. Point taken, though I am still confused about the latter scenario: to me it seems that to some extent if software is useful, it will always have those who come to contribute, even if that is only in repsonse to proprietary expansions on that open source software. But then, and permit the reductionism, what seems to follow is a very zero-sum analysis of the resources of the open source world being made, used, and abused by companies. Moreover, the only kind of company that seems to factor into his analysis is those that are following the open core model, particularly those that are actually quite eager to just make as much money as possible. Now don’t get me wrong, I don’t have any illusions that businesses are run for money and I enjoy seeing the “Prisonner’s Dilemma” and common and public goods theories applied to new realms as much as the next guy, but the fact that Red Hat is mentioned in only brief passing in an article devoted to the relationships between companies and open source software seems revealing.

Buytaert is right to suggest that open source communities - like garage bands becoming rockstars - must be careful in scaling properly, managing continued growth and navigating a landscape of “predatory” companies. But to me discussing how open source commuities should consider sanctuary in much stricter self-governance (raising serious identity issues) or even the “enemies of old” of government and the corporate world, betrays fears of a limited resource being dominated by “takers”. He is careful to make the point that the real and finite resource at stake is consumers, but the open source spirit and continuing history is not a limited resource. Beyond failing to give time to other models of corporate-community interactions in the open source world, I believe the article fails to consider the - pardon the economic pun - “invisible hand” of the open source spirit. Perhaps Tom Callaway has won me over with his views, but I can’t help but feel like companies which circle like vultures and take (make proprietary) whatever they can are playing a losing and limited game. In the open source world it seems as though the more you give the more you benefit, and it is this dynamic that will dominate the future, not free-loading “takers”.

FOSS Project Log:

Monday, May 4

Monday was the beginning of what has become a flurry of group work on OpenCV. I happily awoke to find that the issue I submitted regarding broken NumPy links in an OpenCV tutorial had been responded to by a frequent contributor to OpenCV, who gave me the green light to submit a pull request. Two things were interesting about this exchange: first that he advised me of the proper target branch for tutorial or documentation fixes, which is actually not master in this case (planting the first small seed of an idea for improving on OpenCV’s contributor documentation in our minds). The second item of (more minor) note is that the contributor is located in Russia (this is listed on his Github profile); thus not only is this my first real open source “collaboration” but also my first experience of international open source communication, and I now know that I may have to wait until the wee hours of the morning for a response to a submission!

I quickly responded with a promise to follow up with a pull request, and set about comprehensively reviewing all relevant contributing documents (namely the OpenCV About Page, How_to_contribute, and Writing documentation for OpenCV) and setting up a development environment. The former preparation component actually yielded three further small opportunities for contribution. First I noticed a few small problems with the About Page: two grammatical improvements, an inconsistency in discussing the number of algorithms covered by the library, and two poor links: one suggesting that new contributors check out issues labeled “easy” on Github (it doesn’t appear this label has ever been used and the link should instead likely point to issues labeled with “good first issue”), and a link pointing to an apparently deleted section for bug reports - “creating new tickets” - in the OpenCV Wiki. (Compare the URL with where you land.) I heeded the website instructions that any fixes for the website should be submitted via e-mail and did receive a grateful response, though it does not appear as the changes have been implemented yet.

The second small fix I spotted was another broken link, this time to MathJax documentation, on the “Writing documentation for OpenCV” page. The third, was a slightly incorrect instruction for revising a Git commit hook towards the end of the “How to contribute” page. Before proceeding with any fixes, I largely used the Installation in MacOS guide created by a former student in the Open Source course, who is also a coworker at Geopipe, to set up my development environment! This primarily consisted of cloning the repository, installing CMake and Doxygen, adjusting a git commit hook, and attempting a build from source - which thankfully appeared to be successful. I waited to speak with Boubacar and Jessica to confirm they had interpreted the note regarding the appropriate target branch for pull requests in the same way, before submitting anything. Shortly after starting a meeting on these matters, our experiences in setting up development environments and moving forward, I submitted a pull request for the aforementioned NumPy links issue as well as a pull request for the broken MathJax link. As the slightly incorrect git commit hook instruction was on a Wiki, which we could not offer to revise, Jessica submitted an issue, which was closed after the fix to the Wiki!

Tuesday, May 5

Tuesday involved another contribution and another meeting. In the course of looking for opportunities to contribute in the OpenCV tutorials I had noticed that the table of contents for tutorials on one module needed to be updated to reflect the languages used in two tutorial articles. I decided not to open an issue on the matter, given that I believed it was a straightforward and necessary fix, and I was also wary of opening issues on smaller documentation matters. Instead, as with the MathJax link (where I also did not open an issue), this served as the basis for another quick pull request. In this case, the pull request also served as a convenient platform to ask a question about a particular tutorial which did not yet have a Python component and in which I saw an opportunity to contribute code via a tutorial. As mentioned previously, having a single source of tutorials, with multi-language (namely C++, Java and Python) support is a goal for the OpenCV project, and this seemed like a great way to contribute to that end.

After discussing the various articles Boubacar and I had found to be in need of work, we decided that reconciling and consolidating the main tutorials and OpenCV-Python tutorials on contours (these are listed out on the HackMD) might be a fruitful approach both in terms of the amount of work to be done and in terms of tackling a tough issue for the OpenCV team. We agreed to regroup on Friday after having read through the articles and try to formulate an issue for submission.

Wednesday, May 6

Wednesday involved a small amount of pull request cleanup. Unfamiliar with the preferences of the OpenCV maintainers, I had made two separate, small commits for each change to the table of contents, but, understandably, I was asked to squash these commits for a cleaner history. After a quick review of how to update my pull request and work with git rebase, the pull request was good to go!

Thursday, May 7

Here I was happy to note that all three aforementioned pull requests had been approved and merged! Having noticed further table of contents deficiencies amongst the tutorials in my continuing research, I inquired about how to submit further changes (single vs. multiple pull requests).

Friday, May 8

Following up on the response that I should submit a single pull request with all desired table of contents updates, I submitted a new pull request, updating ten separate table of contents files. Friday also featured an extended meeting with the group regarding the aforementioned contours tutorials, and after some insightful discussion into what steps would be involved, what questions we had, and how the tutorials should ultimately be organized, we submitted a hefty issue. While we simultaneously agreed to take up focused individual tasks of tutorial revisions/improvements, we also concluded that the response received to this issue would be very informative in guiding our approaches to our personal tasks.

Other Course-Related Activity:

Nothing further at this time.