Category: Topics

Within the lifecycle of any project, especially in the dynamic realm of open-source, each potential addition requires iteration, testing, and critical dialogue. While writing the code for a contribution is a significant step, ensuring it meets user needs, functions correctly, and integrates seamlessly necessitates robust methods for user testing and a continuous loop of community feedback. There are several methods for testing contributions and various strategies for communicating with the community, both during development and when sharing the final outcome.

Before my contribution to Jellify even reached the broader community, I made sure to thoroughly test any changes I implemented. This involved not just verifying that the code ran, but also assessing how it interacted with other parts of the application. In many open-source environments, having someone else review your work can be invaluable. They might spot issues or suggest improvements from a different perspective before a pull request (PR) is even created.

The PR itself serves as another critical feedback mechanism. When I submitted my changes to Jellify, the PR was more than just an attempt to merge my code; it was an invitation for review. Maintainers and other interested community members could scrutinize the code, test the associated branch, and provide direct comments on specific lines or overall functionality. If it had been a larger feature, creating a draft PR early on, even with incomplete code, would have been an effective way to signal work in progress and invite early, systematic feedback. This is where detailed code reviews, automated checks, and manual testing by maintainers come into play, directly shaping the final contribution. In my case, I was only able to test my changes using the Android emulator on my machine. Consequently, the project maintainer had to verify that the changes didn’t cause any problems on the Apple platform. Communication during this phase was key; the maintainer provided feedback directly on the PR, confirming the changes worked as expected on Apple before merging. This clear communication ensured everyone was on the same page. Since no issues arose, they were able to merge the code with the main codebase, making it available to everyone else working on the project.

In addition to this “on-the-fly” testing during development, there is also formal user testing, such as alpha and beta releases. Jellify utilized this by releasing both stable and unstable builds for its community to try and test, typically announcing these releases and soliciting feedback through their Discord server. As the app was still in its early stages, all testing was conducted in the alpha phase, where the project’s core functionality was available, but most other features were not yet ready or hadn’t even been started. By releasing the app to a wider audience of over 100 users and contributors, any new problems or suggestions for the app could be discovered quickly, facilitating the rapid formation of potential bug fixes and feature enhancements.

Ultimately, user testing and community feedback are not merely steps in a process; they are the lifeblood of a thriving open-source project. They ensure that contributions are not just technically sound but also genuinely valuable to the people the project aims to serve. My experience with Jellify underscored how these feedback loops, facilitated by effective communication, lead to a more robust, user-friendly, and collaboratively built application.

When considering contributions to open-source projects, the focus often defaults to the technical development involved in building the codebase. However, creating a successful, functional project involves far more than just coding. Even before development begins, crucial groundwork like planning, discussion, and sometimes testing is required to define what will be built.

While I didn’t make design contributions myself, the Jellify community included many individuals who, despite not coding, possessed remarkable design skills. When new project components needed visual or user experience design, these contributors often stepped forward. For instance, Jellify lacked versions compatible with Apple CarPlay or smart TVs. Without writing a single line of code, community members skilled in design developed mockups. These mockups not only visually aligned with the existing application but also incorporated innovative ideas tailored to platform-specific usability. This design work was crucial for expanding potential outreach to users on these platforms and enhanced accessibility by providing developers with a clear visual target. This, in turn, saved development time and contributed to a more polished end product, demonstrating how non-coders can significantly shape a project’s user experience and future direction.

Discussion is another vital, and perhaps underrated, non-code contribution. I believe that evolving an initial idea into a feasible plan is one of the most challenging yet critical phases of any project. Being part of a community where ideas can be openly discussed and refined is an incredibly important step in creating successful and user-centered software. While I made no direct design contributions in terms of creating visual assets for Jellify, I actively participated in several Discord discussions, notably one concerning the menu bar for the app. By offering comparisons with other music streaming services, I helped the team consider different user experience (UX) approaches. This collaborative dialogue, drawing on diverse user perspectives, ultimately contributed to a more informed decision and a potentially more accessible and intuitive interface for all users.

For larger projects, the opportunities for non-code contributions expand further. For example, if a project begins to spread internationally, the need for localization into different languages becomes increasingly important. Jellify hasn’t reached this stage yet, but I can foresee a future where it will require individuals to translate the app’s interface and any accompanying documentation needed by other contributors. Furthermore, as communities grow, so does the need for comprehensive documentation to track code changes and improve accessibility for new contributors. Alongside this, more people will be needed to interact with an expanding user base, manage community forums, and handle social media or promotional activities that highlight new features or updates on ongoing development.

The standard versioning system currently used by most projects is Git, often paired with GitHub. Git is a powerful system for managing project versions and creating branches, which helps isolate changes before they are integrated into the main project. GitHub, in turn, often serves as a central hub or “town square” for open-source projects. Using Git, developers can upload their projects directly to GitHub, complete with all version history and branches. While Git and GitHub can be used independently, their combined use is highly beneficial in most cases.

However, GitHub offers more than just a platform for hosting project code; it provides a suite of tools and features for project coordination and management. One such feature is the “Issues” tracker, where the community can report problems, suggest enhancements, or propose ideas for future features. Each issue can be tracked, discussed, and linked to related items.

In my experience with Jellify, the “Issues” section was where I identified the area I would contribute to. The specific issue I tackled was created by the project owner. They used the Issues tracker not only to document problems reported by the wider community but also to outline their own ideas for the project’s future. This Git and GitHub based workflow was particularly effective for Jellify as it grew, allowing multiple contributors to work on different aspects simultaneously without conflicts, and providing a transparent process for tracking progress and integrating new code. Once an issue was assigned to me, my task was to develop a solution and then create a pull request to merge my fix into the main project.

To implement the fix, the common practice (and the one recommended by to me by the community) was to create a new branch of the project. I first cloned the project to my local machine using Git and then created a separate branch for my intended fix. This approach ensured that when I created a pull request, only the relevant changes were included, and it also helped keep my local working copy clean and organized. Based on this experience, I am confident that I will consistently use both Git and GitHub in future projects. Their utility in managing a project saves significant time that would otherwise be spent on administrative tasks, making them invaluable tools and a real sanity saver. The scalability offered by this system was also evident as Jellify began to attract more developers, demonstrating how these platforms are designed to accommodate growing open-source communities.

The open-source model thrives on collaboration. When individuals can freely download and edit a project, this often inspires them to contribute improvements. This desire to enhance the base project naturally fosters collaboration within its community to update and refine it. In many ways, collaboration begins even before a project is formally established. When an idea for a new project emerges, it’s likely that a few people will resonate with its concept and potential uses. Discussions among these interested individuals represent the earliest form of collaboration. Typically, one person takes the initiative to start the project, often for their own benefit, but this initial effort can quickly attract others. People join in, contributing to development and participating in decision-making. Of course, each project develops its own process for finalizing decisions.

In my own experience with the project Jellify, it is managed by a BDFL (Benevolent Dictator For Life). This doesn’t mean the BDFL makes every choice in isolation; they frequently discuss options with other contributors and users to determine the best course of action. However, once the BDFL makes a decision, it is generally final. This governance model is common and can be seen in prominent projects like Linux, with Linus Torvalds, and historically in Python, with Guido van Rossum. In both cases, these leaders had the final say, but their decisions were significantly informed by community dialogue.

Of course, the BDFL model isn’t the sole approach to governance. Other common structures include steering committees, community governance (often based on meritocracy), or external committees. Each of these models presents distinct advantages and disadvantages, the suitability of which often depends on the specific project. For governance models reliant on a small number of decision-makers, a key consideration is the “bus factor” (the project’s ability to continue if key leaders were to “mysteriously” disappear) especially when long-term sustainability is a goal. Conversely, involving too many lead decision-makers can introduce bureaucracy, potentially prolonging the time it takes to finalize any decision.

I believe decision making is one of the most active forms of collaboration in open source, as it’s when individuals are most deeply connected with others in the project’s ecosystem. While working on a specific issue, you might often work independently unless explicitly paired with someone. This, however, doesn’t mean you are alone. Fellow contributors are usually available to help and collaboratively solve problems if needed. All one has to do is reach out and ask, which is a testament to the supportive environments that open-source communities cultivate. This was quite prevalent in Jellify, where developers would often experiment with different approaches to a problem, then discuss their findings and collectively decide on the next steps.

Having a diverse range of contributors makes a project significantly more robust, especially when everyone actively participates. During brainstorming sessions for new features or potential bug fixes, different people bring varied knowledge and perspectives on all aspects of a proposed contribution. While this can make finalizing a decision more complex, it also ensures that a wider range of possibilities is considered. Furthermore, it increases awareness of potential issues that might arise from an addition, allowing the team to plan and prepare for upcoming changes. A large, active community like this also contributes to a project’s longevity, as individuals become more invested and work towards its continued survival and growth.

Ultimately, the primary benefits of cooperation are the increased speed and efficiency compared to solo development. Collaboration also allows a project to scale much larger, enabling multiple individuals to manage different areas simultaneously. For instance, the sheer size of Linux today would be unmanageable without a dedicated group of members driving its ongoing development and maintenance. In the case of Jellify, when I first joined, the community was quite small, with only a few developers. About a month later, Jellify had grown significantly, with developers spread across various problem domains and porting efforts, all helping to build something they would collectively use.

Open source movement at its center is a vast, interconnected community project. Most open source initiatives aim for the benefit of “everyone”, this huge community is composed of thousands of individual projects and sub-communities, each with its own culture, goals and methods for interaction. For my contribution, understanding how to communicate and working in such communities was incredibly important.

My initial search for a suitable project revealed the size and supportiveness of the wider open-source community. Resources like Stack Overflow, Reddit (particularly subreddits like r/opensource) and dedicated platforms such as helpwanted.dev, up-for-grabs.net and goodfirstissue.com almost invaluable in finding a project to contribute to. These sites act as aggregators, curating project and their issues into a single place. GitHub’s own version of this further streamlines this process, making it accessible for both seasoned developers and newcomers like myself to find projects that align with their interests and skills.

One I identified the project I wished to contribute to, the next step was to get closer to the community and insert myself by offering my help. I found a few different things very useful in finding a relevant issue to work on.

Before I started to actively participate in the project, I spent some time looking over all the current issues, as well as the different communication channels they were using. Primarily they used github issues and discord for communication. This helped me understand the typical tone in how contributors and maintainers interacted and what the typical contribution looked like.

To easily find issues I wanted to attempt, I searched for tags such as “good first issue” or “easy” inside projects. This was my main method for finding a suitable entry point into a project. These issues are intentionally scoped for newcomers, allowing them to start on a easier problem whilst also leaning and understand the current code-base.

As I experienced it, technical discussion was usually made underneath the individual github issues. Here problem were clearly described, assigned, and often debated in hopes of finding the right solution.  This structured approach ensured clarity and allowed for asynchronous collaboration, which was vital.

Beyond the focused discussion on GitHub, the project’s discord channel served as a significant method for community building and engagement. This project offered more informal discussion on diverse aspects of design, potential future features, and significantly, direct communication with the projects users. This was a key strategy for the project to gather real-world feedback and for contributors to understand the user impact of their work. It allowed me to see the bigger picture and the human element behind the code.

In my experience, the combination of these methods of community exploration and understanding was key. The structured environment of GitHub issues provided the framework for technical contribution, while the more fluid, social environment of Discord helped i understanding the communities’ thoughts and needs. The clear “good first issue” labels seem to me to be the most direct and effective method for bridging the gap from an outsider to a potential contributor, making these communities feel quite accessible. These communities have helped me not only to contribute code, but also to begin understanding the collaborative spirit that underpins successful open source projects