Position Statement: Open-Source Movement

General / 20 April 2018

In response to Eric Raymond’s The Cathedral and the Bazaar, I agree that collaboration in software development creates better software. This is not to say that open-source is the only way to achieve this because collaboration can also be implemented effectively even in a closed-source software development environment. Over the past few years, a growing number of closed-source software developers are integrating key elements from the open-source movement into their business and operational practices. Some of this is from a business standpoint to be more open and responsive to users, particularly in addressing support and development efforts. But a lot of it is a direct result of the value achieved through open-source initiatives. To me, the key is collaboration and finding a balance between the business aspects of valuable, proprietary information and maintaining an open dialogue among developers, testers, users, and others involved in the software development process.

Nevertheless, I find a lot of value in open-source projects: using them as reliable substitutes for costly alternatives, to learn how to write better programs, and to collaborate with like-minded people. One of the many open-source tools that I use is Shotcut for video editing. Like many other open-source projects, it is based on and supported by various other open-source projects. It also includes a feedback loop in the form of a discussion forum for collaborating and communication of issues and solutions, as well as a road map to outline and prioritize the development of features for upcoming releases. All of these provide an open communication among developers and users whereby everyone can contribute and be fully aware of challenges and progress, which support Raymond’s reference to “Linus’s Law”. Below are links to the aforementioned Shotcut resources:

  • Discussion Forum: https://forum.shotcut.org/

  • Road Map: https://shotcut.org/roadmap/

  • Credits (list of supporting free/open source projects): https://shotcut.org/credits/

I find it even more interesting to see examples of closed-source programs that effectively uses strategies from the open-source movement, such as Unreal Engine. Its discussion forums provide a venue for users and developers to collaborate and the marketplace resembles Raymond’s “bazaar” where various plugins and other tools are made available, some of which are free and others at cost. The developer’s community pushes and supports the further development of the software through its collaboration and open dialogue, more so because of the many users who are passionate about using it for their own endeavors. This mimics the open-source rule: “To solve an interesting problem, start by finding a problem that is interesting to you” (Raymond).

However, one of the most notable concerns revolves around security, which I believe is challenging to balance. Yes, data-mining user information hints at overstepping boundaries through surveillance and selling it to others, unknowingly to users. I have issues with that and, in fact, I’ve worked with a closed-source projects specifically to test this parameter before I decide to implement its use. And though I’m not an information security expert, I’m familiar with the many ways in which malicious intents can find their way through open-source environments. I believe one of the strengths of closed-source projects is the ability to manage security, particularly as it’s the utmost concern for applications used by the government, military, financial institutions, and the like. In either open- or closed-source environments, the threat of security flaws exist and barriers will always be attempted to be penetrated by entities. This is definitely a challenging aspect of software development and balancing critical elements like security.

The periodic releases of versions show the speed at which it responds to the community with requested updates and features. Several software packages like Unreal Engine include the option to document and transmit logs of activity when a critical event occurs in the software. The user can then include this “background data” in their communication to the software developer for troubleshooting. The users feel that they have been heard and are empowered to further contribute to the community. I’ve predominantly used one of its competitors, Unity, for several projects, but it wasn’t until recently that I used Unreal Engine and its community to develop a project. I quickly realized that its growth over the past years has been extraordinarily fast, a large part due to the devoted community.

Furthermore, in an effort to provide users an opportunity to expand functionality and customize as needed, several software companies allow for users to have access to the software’s application programming interface (API). While this is not necessarily the source code, it is a managed portal to allow for further development of the application by the user without having to rely on the the developer or software company to develop and integrate custom features into future releases. This has proven to be very effective in a lot of my work creating custom automation tools for closed-source software like Autodesk Revit. Plugins and features that are developed get promoted back to Autodesk and the Autodesk community for further refinement, and some eventually make their way back to the core program or become marketable tools by themselves. To a certain degree, even using Blueprint within Unreal Engine is an attempt by the company to allow users some freedom in customizing functionality without providing full access to the source code.

Again, despite not being open-source, the strength of such closed-source tools’ development environment arises from the open communication and effective collaboration strategies, all stemming from the open-source movement. And a lot of companies and developers have attempted to strike the balance of a market-worthy and profitable product with the “bazaar-style” development community.

Works Cited

Raymond, Eric S., The Cathedral and the Bazaar. Eric’s Random Writings. 11 September 2000, http://catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/. Accessed 03 April 2018.