Contribute to Open Source: Daniele Scasciafratte, Part 2

We are back with Daniele Scasciafratte, author of the book Contribute to opensource: the right way, to dig deeper into the book and the best practice for making contributions to FOSS projects. This is part 2 of the interview with him. You can find part 1 here.

Many people may feel intimidated or overwhelmed by the idea of contributing to open source projects. How does your book address these concerns and provide guidance for aspiring contributors?

Every open source project has the same environmental architecture and tools. The first step is to explain how a project lives: the communication platforms/services and the differences between them, and to suggest that you are here to simplify the work for the maintainer. The next step is a personal question asking yiou to understand your needs, like a feature or documentation improvement. The final step concerns the various activities.

I divide these steps into first and second levels and categorize them as having a direct or non-direct impact on the project. Direct activities are tasks whose impact on the project can be seen immediately. In contrast, the impacts of non-direct tasks might be seen after finishing the job.

First-level activities can be done by everyone with zero experience in the project: reviewing, localization, support, testing, promotion, and evangelism. The second level requires more experience and is difficult for newcomers: documentation, community management, and development.

By categorizing contributions this way, I make it easier for everyone to understand how any FOSS project works and reuse the same approach for every project: it’s learning by example.

People are overwhelmed because every project is different, and need clarification about where to start. Instead, looking for everyday things helps; Like when you are grocery shopping, and you have no idea about a new product, you just read the label that explains the ingredients.

Your book covers various aspects of open source contribution, such as choosing a project, setting up a development environment, submitting patches, and dealing with issues and pull requests. Can you provide some practical tips or strategies for new readers to open source contributions?

The first thing I always suggest, whether you are skilled or a newbie, a developer or a localizer, is just read the documentation, even if it’s just the Readme File.

Knowledge is more meaningful when it gets closer to your experience. While working on the first draft of the book, I asked various people to review it, and I saw that a lot of people were asking for explanations for some jargon words or for some stuff that I hadn’t explained and clarified well enough.

Open source is based on people’s feedback: a ticket, a code patch, a reply in the support forum, etc. Why not start by improving something that’s important for the project’s future? I remember a survey from Stack Overflow showing that one of the main selling points for a FOSS project is the quality of the documentation, followed by the community.

Another problem I saw with newcomers is that they want to contribute because they are thrilled by the project, but need help figuring out where to start.

Explaining the various activities helps them understand where they feel more comfortable contributing. Participating in support is the ideal step; it prepares you to move quickly to other things.

Open source projects often have unique cultures, development processes, and coding standards. How does your book help readers navigate these differences and contribute effectively to different types of projects? What is the easiest way to start once the differences are addressed?

Explaining the various communication and platform tools usually is a way to understand the structure of the community: for example, whether it is run by a company or by different contributors, whether it is an old community with old procedures (like mailing list only) if modern with other communication mechanisms, and whether it is welcoming to new people.

\Joining a project with an integralistic approach is something FOSS is (in)famous for. You will have a bias that doesn’t let you participate in the best way to improve a project. I focus on something other than whether the project uses GitHub or GitLab; those are just code hosting platforms with their particular services and policies. I don’t focus on the code of conduct either. It is crucial for sure, but not just when you are in a study phase or in the first steps of contributing to a project.

Open source projects can vary significantly in size, complexity, and maturity. How does your book address the different projects and guide readers to choose the right ones to contribute to based on their skills, interests, and goals?

Any project comes with different needs, so learn their priority, for instance:

• We need more active developers, so we need to simplify the dev environment or improve the documentation for them
• The community is dying because there are gatekeepers who are not so friendly to newcomers
• The project has a lot of users but is not famous outside that community, which means more advocacy to do.

I explain various areas and activities using external resources as well. The 134-page book contains 200 links to such resources as recaps, analyses, and journals where projects explain how they improved something with facts, not buzzwords.

Finally, what do you hope readers will take away from your book? What message or advice do have you for individuals interested in contributing to open source projects but who may need help knowing where to start?

The message is simple: don’t worry and be nice. FOSS is made by humans, and if you are professional, gracious when you are talking to them and reporting a bug that is very annoying for you, it will improve every future move.

Also, if they are an employee paid to work on a project, being nice is always better. We shouldn’t forget about the motto “Free as Beer” at the start of the FOSS.

The book’s title includes the words “the right way”; that’s just a way of saying that some approaches work better. The book starts with my autobiography to give an example of a career in the open source environment.

Each new edition started with me gathering ideas at events, talking with people, and reading Twitter or Reddit to see what people are looking for. This way, I can check a “thermometer” of the FOSS world, like I started doing during the COVID pandemic.

I gather resources to improve the book if I see something that needs to be added.

Right now I’m tracking the rise of AI, but there isn’t anything new in the FOSS sphere here that affects the book (in my opinion), as we already saw with the GitHub Copilot case. Still, after all this time, there are a few new licenses with some specialized rules, for example.

So I am unsure whether there will be a new edition this year because I always decide that I have written everything to say about the “contribute to open source” topic. This is the task for the readers: Reach out to me to report something missing.

Also, an important thing is that just reading the book and writing to me to report a typo, something that’s not clear, or something missing about a topic is in itself contributing to Open Source, as the book is entirely on GitHub and licensed under the free GPLv3 license,. People who contribute are mentioned in the book.

We are getting close to 1,000 downloads, and it will be a new record because the work is only self-promoted.

I think a relevant example of the 3rd edition is the “boy scout rule” I mentioned to explain my purpose and my approach to the book and to open source:

“Always leave the campground cleaner than you found it. If you find a mess on the ground, you clean it up regardless of who might have made it. You intentionally improve the environment for the next group of campers.”

Source: lpi.org