Some thoughts on Open Source Development

I think there are several interesting and useful aspects of open source to consider. These are 1) the utility of open source to consumers and organizations, 2) the principles of information freedom, and 3) the interactions of open source with the modern economy, particularly the challenges facing open source companies and the tension between economic constraints, the profit motive, and information freedom.

On the first point, it is clear that open source software is the cornerstone of modern industrial society. Without open source software, the boom in the software development industry would not be possible. It is attractive to frame the success of modern startups as a result of the genius of their founders and various involved professionals, and there is certainly much truth to that, but the value derived from open source software by every single startup and well-established software company is immense. Without open source, that is, if every piece of software needed to be licensed by the enterprise, and judged profitable by the vendor, the modern tech company and especially startups would be impossible. The corresponding value for consumers is also immeasurable, it means the can access countless service at low cost, since the production costs of software is correspondingly reduced. And this is only counting the indirect benefit of open source, the benefit derived by the fact that closed source consumer-facing software uses open source under the hood, they also derive major benefits from using open source software directly, and by having open source in direct competition with closed source software, in whose production profit is the only conceivable motive.

So its clear that open source software brings major benefits to society, but without a corresponding organized workforce dedicated to producing it, open source would remain amateurish, obscure, and either low-quality or limited in scope. So organizations must be formed, and must make a profit (at some point at least; even Mark Shuttleworth would have run out of money eventually). Aiming to contribute to the common good is not the only motivation to be an open source company of course, a cynical approach could identify open source as a feasible and advantageous business model without any consideration for the good of humanity. For example, Red Hat may have been founded and run with altruistic goals similar to Canonical’s but does IBM share its altruism? I think not.

Regardless of motivation for entering open source, an open source company has both advantages and liabilities when it comes to their business model. On the one hand, a major advantage of participating in an open source community and basing a commercial product on that project is that a major component of development work can be done by the community as a whole rather than by the company directly. This is an advantage over competing companies which are not in a position to use the project, but may also be a disadvantage in that other companies are able to use the project without contributing. There exist several examples of the latter in AWS, which freely takes open source projects and sells them as a service. This has contributed to controversial source-available software, such as by Redis using a Commons Clause in its newer license to prevent monetization. Orientation towards an open source community also brings constraints, since the project leaders must incorporate other priorities, motives, and use-cases beyond what is strictly marketable. Also decisions cannot be made which the community will reject, lest a fork occur. These are constraints which Canonical has but which Microsoft does not, the latter is free to engage in their countless morally abhorrent practices without reproach. A further benefit to corportate open source is that it is possible to become a hegemonic solution in a new domain by not limitting adoption to those who can pay. If the product could be adopted and tested and contributed to by enthusiasts, it can become well-known without additional cost by the company. One might consider the various articles, Stack Overflow posts, school projects, etc. that use the project as a form of marketing, coming at no cost to the company. This comes with the constraint of requiring a monetization model. In the case of a freemium model there is a need to balance between a free product that is useful enough to trigger adoption and build a community, but still lacking features such that a sufficient number of users will desire to purchase the pro tier, but not lacking so many essential features that free users would rather opt for an alternative, this is contrasted with the “related services” model, and a SaaS model, but I won’t proceed with a detailed analysis of the pros and cons of each approach.

I hope my long discussion of economic incentives did not seem impertinent; I find it useful to start at the beginning, since economic factors shape the communities in which we live; this is as true for IRL communities as for virtual ones. The dynamics of open source projects then, are determined by the economics of modern society and by the shared and divergent interests of the organizations and individuals which participate. So, having established the utility and constraints associated with open source communities, we must ask: “What development and community engagement practices are conducive to building open source communities?” • To mediate conflict, it is useful to establish strong personal relationships between contributors. Forum engagement and in person events and conferences can contribute to this. • The project leaders must be open to criticism, which won’t always be in good faith. This is easier said than done, since it can be difficult to accept criticism about a project you’ve put enormous effort into from individuals who have sometimes contributed very little (so far). • The scope of the project is likely to be widened, since other individuals and contributing organizations will have their own priorities, it will not be possible to accommodate all use-cases, but accommodating as many as possible will serve to widen the community. It can also help with product development, there may be uses or marketable features/use-cases which the leading organization did not consider, but can benefit from. • Documentation should be impeccable. This will make it easier to onboard contributors and users. • Code quality should also be incredibly high. Only the most ardent enthusiasts will bother to contribute to a project with an obfuscated codebase. • Similar factors apply for all other aspects of software quality. Both contributors and users of the project will be much more diverse that the company itself, contributions are more like to be (initially) low quality, or inconsistent with the project’s standards. Consumers are likely to use the software on a wider diversity of systems and environments. The result is that code review must be extra thorough, and CI extremely detailed. There is also the possibility of malicious contributors.