Understanding How Open Source Projects Work

In a survey conducted with nearly 150 passbolt users, we discovered that a majority of those stated that they do not contribute to open source projects was because they don’t:

• know where to start 15%
• have the necessary skills 50%
• have the time 28.75%

We’ve already addressed the fact that you probably do have the skills needed to contribute — it’s just a common misconception that programming is the only contribution that makes a difference.

As for having the time, contributions can be big or small. Every little bit counts. You shouldn’t feel like you have to make a large contribution for it to be worthwhile. Something as simple as leaving your feedback or sharing an opinion in our forum is a valuable contribution!

What we want to focus on here is for those of you who don’t know where to start. We’ll break down the basics of open source projects to help get you going. And, hopefully, of course, inspire you to start getting involved with open source projects.

The Cathedral and Bazaar

Not every open source project follows the same organizational model. Some are very large and highly decentralized. The majority are quite small and centralized around a few key people.

Eric S. Raymond, in his essay/book The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, contrasts 2 development models for free software; The Cathedral and The Bazaar.

According to Raymond, The Cathedral is where source code is available with a software release. The code developed between releases is only available to a restricted group of software developers.

The Bazaar model is where the code is developed over the internet publicly. Raymond credits Linus Torvalds (leader of the Linux kernel project) as the inventor of this type of free software model.

Anatomy of open source projects

There are a lot of people interested in open source projects — maybe you heard a friend talk about one they’re involved with. Perhaps you use open source software, like passbolt, in your daily life.

Breaking down the anatomy of open source projects is a great way to better understand what role you can play. Not everyone who codes is an open-source expert, and not all of us are developers anyways.

First things first, we need to break down the different elements of an open-source project.

Who’s who?

Typically, in an open-source project, you’ll find the following roles.

Original Author → The person who created the project and has the power to assign new roles to other members for project maintenance. Depending on the project this person can have a lot of influence and acquire the nickname of “Benevolent dictator for life”.

Owner → Has administrative ownership of the project (can be the same person as the author). In some projects, like passbolt, a company can be the owner.

Maintainers → Responsible for driving the vision and goals of the project. Usually, people who feel responsible for the direction of the project and are committed to improving it.

Contributors → Add to the project. They follow the same code review process, are subject to the same requirements on code style, etc.

Community Members/Users → Valuable members of the community who provide feedback about features, bug reports, etc.

What’s it all about?

Now that you’ve got a pretty good grasp of who’s who in typical open source projects, we need to figure out what the project is about, find out about their licensing, guidelines, and any other information that will help you to take part.

License — Open source doesn’t just mean access to the source code. All open-source projects must have an OSI-approved license! This license protects the freedom of the contributors and users.

Readme — A manual that explains how to get started with the project. A good README will have everything a potential contributor needs to know about the project.

How to Contribute — Guidelines that help people contribute and show what type of contributors are needed. This file isn’t mandatory, but great when a project has one.

Code of conduct — A document that establishes the author and owner expectations for how the contributors and participants behave. Usually used to create and maintain a safe and positive environment with the community.

Sharing is caring

Beyond creating a positive environment in an open-source community, most projects will also want to ensure that users and contributors feel comfortable enough to share, and be open about their opinions. While also making sure that contributors know how valuable their code, feedback, or any other contributions are.

Some of the tools open source projects will use to make this possible include:

• Issue Tracker — Where people discuss issues related to the project
• Pull Requests — Where people review changes in progress
• Synchronous Chat Channel — Specifically meant for people to share their ideas and have conversations (like Slack, or a forum)

At passbolt, we use Github for Issue Tracking and Pull Requests. For discussions, we have our community forum.

Why contribute to passbolt’s project?

Well, we’ve determined you must have some skills that are valuable to passbolt’s open-source software. Plus, now you know exactly who’s who and what’s what in typical open source projects.

Your contributions help to continue the development of passbolt, and the features that users are looking for. The more features there are, and the better they are means that we can continue to grow, together.

The added bonus is getting to be a part of a wonderful community. The passbolt community is pretty tight-knit, very supportive, and we’re always welcoming new insights, ideas, and skillsets. Join in!

Article originally written by Sona Kerim