In my Software Portability and Optimization class, we were discussing about the future prospects for this course. The professor is interested on giving us the opportunity to contribute on open source projects, with a focus on portability and performance in mind. Thus, what a perfect opportunity to learn how Open Source software gets developed, right?
When people talk about open source projects, they always think of the same keyword 'contribution'. This concept is integral to free and open source software as a whole, since this is how free and open source software can sustain itself for decades, with support from several other developers.
While contributing is a ubiquitous in open source projects, there are these small differences that help to lead the development of a project. Differences such as the way projects file issues, bugs, improvements, influence the project and its direction, even at the smallest of scales.
I decided to research these differences in open source projects. I had two open source projects in my mind for a long while, those being the Rust programming language, and the Simple DirectMedia Layer library (SDL or libsdl for short).
I would like to start with the SDL library.
Simple DirectMedia Layer
The Simple DirectMedia Layer is a library that is commonly known used to develop games from the ground up, since it provides low-level access to resources such as graphics, audio, and controls.
The SDL library process to contribute is fairly straightforward: file an issue, and optionally, a PR that addresses that issue. You may also contribute just a PR, as long as you are addressing an existing open issue.
Let's see, for example, this PR regarding some triangle rendering feature. I have chosen this PR since it is the one that is the most commented on, which helps to understand how a PR might go in this project.
We can tell that the PR went through a detailed discussion that touched certain topics such as the efficiency of the implementation, as well as its simplicity of usage. Also, this PR had some background already, referencing two existing issues, so we can deduce that there was a lot of technical discussion regarding this feature. While it might be due to the nature of the PR, this discussion does require a lot of technical knowledge regarding SDL and other surrounding technologies (OpenGL, Vulkan, etc.).
Thanks to this detailed and technical discussion, the PR author improved their code over several commits until one of the maintainers of the SDL library approved his PR.
We can extract some key points over this method of accepting patches:
- The code can be thoroughly discussed with several points of view, that includes other contributors and/or users of the library.
- It requires a lot of technical background to contribute meaningfully to the discussion, so even if someone was a user of the library, this might not be enough to be able to contribute.
- The less-structured process gives more flexibility to the maintainers, as well as the contributors, to manage the code base. However, it does make organization of the issues and PR more difficult to keep track of.
The previous key points may be taken as pros or cons depending on the person, but I personally think that the current process fits the SDL library and its developers.
The other project I wanted to touch on is the Rust Programming Language.
The Rust Programming Language
Rust is known to be a language that intends to promote memory safety with high level constructs and low level speed. Rust is also open-source, and is also open to contribution.
Rust's approach to contribution is a more formal one. This is understandable, since a programming language that is used by several developers has to maintain a philosophy of design, and when the language's features start to overwhelm the core team of the language, it is preferable to set common guidelines for anybody who is interested on contributing.
Rust's process is so organized, in fact, that there is a public guide available.
The process usually goes from a Pre-RFC phase to a RFC phase, where there is a main feature being put to the test and discussed over a relative amount of time, depending on how complex or important the feature is. Let's view the PR regarding the implementation of async/await to the language as an example. This PR does not discuss the semantics or technical details related the implementation of asynchronous programming features. Instead, this PR discusses the syntax and ergonomics of such feature.
One may be surprised that the PR thread contains over 300 comments, all around discussing the topic of ergonomics of asynchronous programming in Rust.
This is not surprising at all, since the Rust community tends to be very open to a diverse audience, and such is reflected in their contribution process. Several developers, with diverse backgrounds, all contributed to the discussion to solidify the ideas that the RFC set.
There are some important ideas we can mention from this:
- Rust's RFC process for accepting features gives the core team ability to organize, prioritize, and target different issues and PR depending on their focus. This, however, introduces administration overhead that the team has to worry about.
- Thanks to Rust's very open community, even newcomers to the language that have been using the language for a few months can contribute to such discussions. However, this may be counterproductive at times, since the discussion might go over some points that have already been taken care of.
- Thanks to such a thorough and formal process, the PR can be improved and tuned over time, so that when it reaches the core team's review phase, the PR represents not only the original idea, but also the design decisions the core team might need to take care of when stabilizing such features into the language.
Conclusion
Open source projects have an advantage over closed source projects: everybody can contribute. With proper diligence, a project can get better and better with everybody's ideas and points of view. The contribution processes that each project employs is usually fit to the scope of the project, the availability of the maintainers, and the nature of the project itself, and thus, there is never a 'One Truth Way Only' to organize the process of contributions of a project.
Top comments (0)