The idea of broad openness in all systems around us, while seemingly extreme, is what I believe is necessary in the future. Specifically, this article will discuss the software side of this topic, concerning proprietary applications and their impact, as well as the effectiveness of open source projects. While this is somewhat based in fact and observations from myself and others, it is important to preface this with the idea that this is my opinion and my thoughts on this topic, and this article is mainly exploratory into the philosophy of openness in technology and its impacts.
The nature of proprietary software is well-based and grounded, with reasonable motivations and causes for such common qualities of it. Proprietary software and closed developmental practices, for better or for worst, is objectively common practice among the industry, and is generally looked at as the most practical and developed mean for developmental openness. The common attributes of proprietary software includes the closed nature of source code, very limited external knowledge about the internal application(partly due to limited access to the source code), restrictive rights over specific use, modification, redistribution, etcetera. A very close principle fundamentally to this is copyright law and the usage of that. For many, if it is feasably possible for a disadvantage to due external use or abuse of your idea or product such as the creation of close competitor products, it is absolutely necessary to protect this under copyright law. While this allows for very limited large scale or corporate sabotage or coattail-riding, this in common practice widely restricts freedoms and the effectiveness of creativity and ideas. Truly, the closed nature is an evil, yet it is not always necessary.
Simple protection over inventions or ideas has the potential to greatly help the creator succeed in bringing the product to the real world with the removal of some major barriers concerning competition or use. On the other hand, large corporations have the cogent power to create a centralized ecosystem of sorts, encircling all of their products for ultimate end-user entrapment. Centralization, while a entirely separate discussion, is a crucial role in the exploitation of such proprietary licenses. Using these tools, companies can create an effective prison for those involved and a fortress for those attempting to escape the confines of the limitations. These seemingly simple license terms, while potentially beneficial to those in specific scenarios, allow the field and industry to create an ideal profit situation for them, with punishments for those who rebel against their ideas. These situations can be observed in many common companies currently, such as Apple. They have created an “ecosystem”, where many needs are satiated, yet many needs still rely on the company to have goodwill and the desire to benefit the end-user over the company’s ultimate profit.
A relatively common argument in privacy is “I have nothing to hide”. Mainly, this concerns the topic of surveillance or large-scale data collection of a user, but this topic is very applicable to the discussion of openness and proprietariness. A key pusher of such an argument is commonly the consumer of ecosystems mentioned previously. As long as it provides some benefit to them(or has some cost to remove), many are fine with playing a part in company schemes. The crucial problem here is the submission into or willingness to follow a company’s practices as correct. As many “submit” into these technological ecosystems, the apparent effectiveness of this strategy increases. Once it is adapted and shown to be extremely effective by some, it becomes nearly common practice for everything as a whole. While the end-user may benefit in some form from having all their applications sync together or be developed by the same company, it sets a crucial precedent for the technologies and companies aronud them; the ability to fully capture the user and set your own standards is extremely important for many company’s successes and sustained growth.
To preserve transparency, I must say I am an avid user and supporter of open source projects and an open nature overall throughout technology. However, it should be known that these arguments still present a real subject matter, with real consequences.
This closed and exclusive complexion can be attributed as simply a “necessary evil”; yet fundamentally, a major shift towards a more open and free(as in speech) industry is possible, but it requires the change of many principle ideologies. “Open source” projects contribute to this overall adjustment, yet are not the defining factor for such. They can begin to present what a more open system can appear like, but do not make the systems as a whole open. However, the practicality and effectiveness of open source maintains as an integral topic, as it can often be a catalyst for the more influential changes. Here will be discussed this idea, as it is a topic in this system of thinking that can be a paramount barrier for many to begin.
Open source project security is a crucial point of decisiveness and deterrent for many. A completely open model of development clearly appears to present benefits to attackers and malicious users compared to a proprietary model. However, this model does not provide the apparent detriments to the overall security of an application as many believe. As discussed earlier, while a closed and exclusive nature can provide clear and non-negotiable benefits, such as the protection of integral algorithms or processes that provide an advantage application-wise, the general idealogy concerning this allows for much more malicious behavior. Regarding the attacker and the viabilities they possess with an open source application, the extent in which they can truly cause damage is very limited. The codebases’s availability to anyone seems to allow attackers to discover and exploit much more vulnerabilities than previously. However, the practicality of this method is extremely limited due to the size and breadth of many application’s codebases. Scanning tools that automatically find vulnerabilities or code issues are something an attacker may posses, but the presence of these within the open source application itself is very common and standard. The attacker may not have a need to scan the entirety of the codebase, and may meticulously investigate a highly security-sensitive area of the code as a potential attack vector, such as a parser that ensures no bad file extensions are uploaded to a website. The applicability of such a vulnerability relies on the incompetence on the level of those approving and reviewing code. This dependency of the lack of awareness of security consequences, while effective rarely, is the lead cause in a general lack of exploitation and attacks present openly in these applications. Simply, reviewers and those with the power to modify the codebase are experienced in the application’s structure and potential consequences of various modifications. The scrutiny that goes into and the public view of proposed code modifications set a precedent for code quality and standards, and crucially prevent security vulnerabilities at the source, rather than preferring to control the damage caused by exploitation afterwards in proprietary software.
The practicality of the open source model is often questioned, as well. The benefits and systematic change in thinking, on the other hand, greatly eclipse the detriments or increased workload that may be caused. Integrally, open source applications allow for greater iteration, cost-effectiveness, flexibility, and overall development speed. The community support of an open source project is significant to many of these factors. Regarding iteration and cost-effectiveness, this support allows for a lessened dependence on a core, internal team of developers, and allows for development based on personal interest and passion of a topic, compared to development for the sake of income and wages(see “The open source paradox” by antirez). Furthermore, an open source application’s flexibility and development speed benefit off of the model. This openness allows for rapid development and testing of possible solutions, and facilitates a larger, community-based structure for this. As shown by the widespread adoption of what works in the corporate world(such as the creation of ecosystems), the paradigms set by some can have a major impact on an industry or related companies. The commitment to openness, even through the minute cost of open source adoption, sets a beneficial precedent for neighboring companies and the industry as a whole.
Nonetheless, open source applications themselves have consequences explanatory for the avoidance of adoption. Commercial viability, licensing issues, and relaxed component integration pose major problems in the open source model. The lack of an ability to sell and commercialize the end-product impact the application’s success, if fully open sourced. In addition to this, common open source licensing terms can be greatly restrictive on many factors of a project. This common licensing impacts the ability to freely integrate external open source components, as many components or their licenses in tandem can conflict and arise problems. Furthermore, these licenses and this model of openness can cause issues regarding intellectual property and the protection of it. While the idea of open source itself can encourage complete openness in the codebase and project, this is commonly unnecessary. Disregarding smaller, community-driven projects, as mentioned earlier, the adoption of open-source should be considered a step into the ideology of openness, rather than the ultimate cause of openness. The full consideration of this allows for much smaller, less significant sections of an overall project to be fully open source and free to community modification. This can solve the potential of discovery of impactful security vulnerabilities in the core of a project, as this may be unnecessary or impractical to open source. An example of all of this is Twitter’s(known by some as X) adoption for the open sourcing of smaller parts of Twitter that may be beneficial to the community, such as their many internal libraries and solutions to common problems(see Twitter’s open source projects).
Openness in systems in technology or otherwise is often opposed, whether for valid concerns or as commonplace. I believe this system of thinking should be more widely evaluated, as it does provide many benefits to the resulting software, system structures, and effectiveness of this model as a whole. This system can have many obstructions as discussed, but the real consequence of proprietariness and the benefits of adopting openness requires serious, but meaningful consideration at a higher level.