Jonathan Desrosiers: Offering Criticism in Open Source Projects
A recent episode of the Crossword podcast had me thinking about offering criticism constructively in open source projects. Jonathan Wold and Luke Carbis were discussing the new Notes feature in WordPress 6.9, which was added as a building block for real-time collaboration. Luke mentioned how he was curious about the reasoning behind the related technical decisions. He was having some difficulties and was a bit concerned about the choice to use the preexisting Comments APIs with a new comment type to build out the Notes feature. The part of this conversation that I really found interesting was when they discussed how it was unfair to the contributors who did work on the feature for him to complain or criticize without knowing the full background of why it was built in the way that it was. I’ve heavily condensed and paraphrased, so I definitely recommend giving the episode a full listen. This premise stuck with me and sent me down several rabbit holes, each one leading to a different dynamic within open source communities. When is it acceptable to be critical in open source? Is it fair to offer criticism when you don’t have all of the information? If so, what is the right way to go about sharing? Who is allowed to criticize? When is it appropriate to solely observe rather than attempt to participate? How do you transition from an observer to a participant? Let’s dig into these questions a bit more. Who Can Contribute? The simple answer to this question is anyone and everyone, of course! It is open source after all! But don’t stop reading because it’s not actually that simple. While everyone can participate, there are so many forces at play that impact how you should contribute. Knowing what these are, understanding them, and being able to recognize them can help make your open source journey a more successful and rewarding one. I won’t be covering contributing from the perspective of specific disciplines (ie. code, documentation, testing, etc.), or even different ways of contributing (ie. financial, time-based, etc.). Instead I’m looking to define two broad “states” of contributing, how to move back and forth between these two groups, and how to communicate better so that everyone feels welcome to contribute. First let’s establish what these two groups of contributors are. CC0 licensed photo by Blazej Zablotny from the WordPress Photo Directory. Passive Contributing Whether they know it or not, every single user and consumer of an open source project contributes back in some way. When you use a piece of software (whether it’s open source or not), you are using your voice (and in some cases, your wallet) to communicate that the software is valuable to you. “This piece of software solves a problem that I have.” Over time, continued usage turns into a second layer of feedback. “This piece of software continues to solve a problem that I have well enough to continue using it.” I like to think of this as “passive contributing” because it happens naturally through the normal use of software without any additional level of effort required. The examples I gave above are the most simple and pure examples of passive contribution and may not seem that useful. But passive contributions can be quite significant at scale. Every WordPress site checks if there are available updates for plugins, themes, and Core itself every 12 hours. However, a few details are needed to ensure an accurate answer is given, such as the version of WordPress the site is currently running, the site’s PHP and database versions, the PHP extensions loaded, etc.. Now consider this happening across tens of millions of WordPress sites. This becomes metric-based telemetry and the data helps paint a larger picture of what the “typical” environment is for a WordPress site. This data allows contributors to make well-informed decisions about the software itself. What should the minimum required version of PHP be? Should a native PHP extension be required to run WordPress? Understanding the actual real-world state is essential before making certain changes, especially in a project so staunchly committed to backward compatibility such as WordPress. Untapped Potential In many ways, this group is the most exciting one in open source. There is so much potential to tap into! One thing that I’ve learned is that you never know what will inspire someone or how they will discover contributing. This is just one compelling reason to underscore the importance of working in the open. “Each interaction with a user is an opportunity to get a new participant.” Producing Open Source Software – Carl Fogel As maintainers of open source, we need to consider this group as much as possible. Since most passive contributors are simply users, the user-focused philosophies of the WordPress project help to keep this group front of mind. CC0 licensed photo by Blazej Zablotny from the WordPress Photo Directory. Active Contributing Conversely, if someone contributes to an open source project knowingly, they fall into the second type: active. These contributors are the backbone of every open source software project. They’re intentionally spending their time filing bug reports, building out new features and APIs, reviewing patches, translating strings, writing documentation, and so much more. In an ideal world, many more passive contributors are activated than the number of active ones who leave a project to ensure growth. But be warned, if you’re ill-prepared to support newly activated contributors, they can easily become ghosts that quietly haunt the halls of your project. Some Additional Considerations I tried to clearly define these two buckets to encompass everyone. But like the question of “who can contribute?”, there is additional nuance to be aware of. Awareness Of Passivity One important thing to note is that individuals may not even be aware of the fact that they are passively contributing. Some (likely most) have no idea about what contributing is or how it works. In other cases, someone can be aware and intentionally choose to remain passive. This was the case
Jonathan Desrosiers: Offering Criticism in Open Source Projects Lire la suite »






