Main Forge Your Future with Open Source: Build Your Skills. Build Your Network. Build the Future of Technology

Forge Your Future with Open Source: Build Your Skills. Build Your Network. Build the Future of Technology

Free and open source is the foundation of software development, and it's built by people just like you. Discover the fundamental tenets that drive the movement. Take control of your career by selecting the right project to meet your professional goals. Master the language and avoid the pitfalls that typically ensnare new contributors. Join a community of like-minded people and change the world. Programmers, writers, designers, and everyone interested in software will make their mark through free and open source software contributions.

Free and open source software is the default choice for the programming languages and technologies which run our world today, and it's all built and maintained by people just like you. No matter your skill level or area of expertise, with this book you will contribute to free and open source software projects. Using this practical approach you'll understand not only the mechanics of contributing, but also how doing so helps your career as well as the community.

This book doesn't assume that you're a programmer, or even that you have prior experience with free and open source software. Learn what open source is, where it came from, and why it's important. Start on the right foot by mastering the structure and tools you need before you contribute. Choose the right project for you, amplifying the impact of your contribution. Submit your first contribution, whether it's code, writing, design, or community organising. Find out what to do when things don't go the way you expect. Discover how to start your own project and make it friendly and welcoming to contributors.

Anyone can contribute! Make your mark today and help others while also helping yourself.
Year: 2018
Edition: 1
Publisher: Pragmatic Bookshelf
Language: english
Pages: 224
ISBN 10: 1680503014
ISBN 13: 9781680503012
File: EPUB, 2.55 MB
Download (epub, 2.55 MB)

Most frequently terms

You can write a book review and share your experiences. Other readers will always be interested in your opinion of the books you've read. Whether you've loved the book or not, if you give your honest and detailed thoughts then people will find new books that are right for them.
Why Is This Book Not Openly Licensed?

Yeah, I thought someone might ask that.

With the growing awareness and importance of open source along with the explosion of new projects released every year, it’s more important than ever that there be a resource to enable and support the immense number of new contributors we’re going to need to help maintain that software. This book is that resource.

While this book needed to exist, and I was well equipped and well placed to write it, it wasn’t going to happen if I did it on my own. Without external help or motivation, I know that I would never finish a project this huge. I mean: writing a book? That’s really intimidating.

To make this happen, I needed help. Enter Pragmatic Bookshelf. Their experience and support could guide and motivate me to create this book, but only if they administer the copyright of it. This allows them to do things like negotiate translations and similar administrative duties, with which I have no experience whatsoever.

The choices were:
	I assign copyright of the book to Pragmatic, then have their invaluable support to help bring it into the world, and Pragmatic chooses a book license based on their current business practices.
	I retain copyright, but I do it alone and unsupported, so the book is never started, finished, nor released under any license at all.

This book is an important resource that is long overdue and will help thousands of people and free and open source software projects. That it finally exists is more important to me than my copyright. So I chose Option 1. I have no regrets. Pragmatic are great people.

Triage Issues

We talked a bit about issue triage back in Chapter 5, ​Make a Contribution​, but that was in the context of an issue or feature you wanted to work on yourself. While this is useful, you don’t have to be the one to fix the bug to be the one to test whether it’s actually a problem. Bugs and feature requests come in all the time for FOSS projects, and it can be helpful to have people reviewing them as they come in, exposing the signal amidst the issue noise. While some projects prefer that more experienced contributors triage issues, others are thrilled to have less experienced people lend a hand as the first responders to any new issues that arrive.

Before you start triaging issues, take a moment to confirm not only that the project welcomes this type of contribution from people of your skill level (whatever that may be) but also how they prefer triaging be handled. One of the reasons projects avoid having less experienced people triage their issues is that those folks aren’t as familiar with the project’s issue tags, severities, priorities, or workflow. For instance, in some projects issue triage includes defining each issue’s severity and its priority on the roadmap. Less experienced contributors often lack the big picture view necessary to make these severity and priority determinations, so some projects prefer that only very experienced contributors perform triage. Mis-tagged issues can cause a delay in fixing issues and require a lot of time to clean up, so some projects avoid this by limiting the people who may triage and tag issues. Check to see whether your project is one of those before you spend a lot of time trying to duplicate a newly reported bug. As always, if a project has guidelines or documentation for bug triage, read and obey these guidelines.

While you probably won’t need to commit any changes to the repository to triage issues as they come in, you will almost assuredly need to have a testing/development environment set up, if not also need to be running a local copy of the project. This can take a fair amount of time to prepare, and will require maintenance to keep up to date. If you’re already contributing changes to the repository, this setup and maintenance time may not be that big of a deal. If you’re not, be prepared to invest time in this. Triaging and testing issues against an out-of-date setup or install only wastes your time.
Don’t Forget to Read First

The first step of any issue triage is to read through the issue. Yes, I know: groundbreaking revelation, right? In all seriousness, though, you’d be surprised at how many people dive in attempting to duplicate an issue before they fully understand what it is that the issue is trying to describe. This can lead to a lot of frustration and wasted time on all sides, but is relatively easy to avoid simply by taking a “read first, understand second, act third” approach.

As you’re reading through the issue, if it appears to be reporting or is at all concerned with a matter of privacy or security, escalate it immediately. Security should never be taken lightly, and it’s always far better to be safe rather than sorry where information security (infosec) is involved. Even if you’re a seasoned infosec specialist, always notify the core project developers that there may be a security problem. This is not the sort of thing you want to surprise people with at the last moment. Notify the team and allow them to prepare to fix the issue, should it prove to be a legitimate concern.
Tips for Triage

While the actual steps for triage will vary from bug to bug and issue to issue, the following guidelines can apply to nearly every issue you look at.
Does the issue even make sense? Be it a difference in perspective, understanding, or language, sometimes an issue will arrive and you simply can’t comprehend what the reporter is trying to say. That’s OK; communication problems happen. Reply back asking for a clarification. It can help to guide the conversation with a statment such as, “I think you mean… Do I have that right?”

Do you understand the issue? Can you tell what the problem is, or is more information required? If the latter, politely request it from the person who filed the issue.

Is it formatted correctly? Many projects have an issue template or provide issue-creation guidance in their CONTRIBUTING file. If your project does this, check to make sure the person who opened the issue followed the template or guidance. If they haven’t, politely direct them to the instructions and ask for corrections to the issue they filed.

Is the issue for a platform the project supports? Some projects don’t work (or aren’t supported) on all platforms. If the person who wrote the issue doesn’t mention platform, politely ask for it. If the platform is mentioned but is one the project doesn’t support, close the issue with a polite note explaining the reason.

Is the reporter using the latest version of the project? If the reporter doesn’t mention the version of the project they’re using, politely reply back and ask for this information. It can be difficult to troubleshoot issues that are made against older versions of the project. It’s also possible that the reporter’s issue is resolved in more recent versions. If the project doesn’t explicitly state that it supports older versions, politely ask the issue reporter to upgrate to the latest version of the project and try to duplicate what they reported.

Is the issue a duplicate? Search the issue tracker (for both open and closed issues) to see whether this issue has been reported before. If it has, politely close the issue as a duplicate. Some projects track duplicates through tagging and/or cross-referencing, so be sure to follow the correct procedure for your project.

What category is the issue? Is it a bug? A support request? A feature request? Noise/spam? Tag the issue accordingly to make it easier to find in the future (or close the issue if it’s just spam).

Are there steps to duplicate the problem? If the issue is reporting a bug or a problem with the project, has the reporter included steps for how to reproduce the problem? If not, politely reply asking them to provide these steps.

Can you reproduce the problem? If the issue is reporting a problem, can you reproduce it? If so, add a note to the issue including the steps that you used to reproduce it and anything new you learned in the process. If you can’t reproduce the problem, it may be that you don’t know enough to duplicate it. That’s perfectly OK. Make a note that you can’t reproduce the problem, then either politely ask someone for help or move on to triaging another issue.

While these tips are for triaging issues you don’t intend to work on, they apply just as well to those you do. So if during your triage you find that you’d like to fix an issue that you’re looking at, don’t hesitate to follow your project’s steps and guidelines for contribution.

Review, Revise, Collaborate

Before your contribution is merged (pulled) into the origin repository, someone will review it to confirm that it does what you think it does, that it does something the project needs, and that it conforms to all project styleguides and standards. They probably will have questions, feedback, and suggestions about your contribution. Collaborate with them to get your contribution into an acceptable state. When you apply their feedback, use atomic commits to your feature branch. As you push these changes, they automatically appear on the pull request. This means you won’t have to do anything special once you’ve applied all of the feedback and suggestions. Your contribution can simply be merged into the origin repository.

Congratulations! You’ve just made your first contribution! High fives all around! 
Submit Work in Progress for Early Feedback

The process I just described implies that you should wait until your contribution is complete before sending a pull request to the project, but that’s not always the case. Sometimes it can be very helpful to send a work in progress pull request while you’re still creating your contribution. Just put WIP: at the start of your request title to let the reviewer know that you haven’t finished the work quite yet. Also mention in the description that this is a work in progress and include any questions you have.

Why would you submit a pull request before your work is complete? For starters, doing so allows you to receive feedback early in the creation process. This can help you avoid going down some dark, thorny paths. Also, higher quality contributions come from receiving early feedback. The earlier and more often you receive feedback, the more likely it is that your contribution will be of a high quality. Finally, sending a work in progress pull request allows the project to see that someone is working on something, so they won’t be surprised when a contribution appears in their pull request queue.

An example of a work in progress pull request:
	​ 	TITLE:
	​ 	WIP: Testing new section ordering
	​ 	I've re-ordered the sections of this chapter in hopes
	​ 	they'll flow better. WIP PR so Brian can have a look
	​ 	and let me know what he thinks before I go much further
	​ 	with the writing.
	​ 	For issue #40

A Note on Feedback 

This is a good time to pause and talk about feedback.

Not to put it too lightly, but feedback is great. Without feedback we keep making the same mistakes. Without feedback we can’t learn and grow and evolve. It’s one of the keys that makes free and open source collaboration work.

Unfortunately, most of us have a very hard time receiving feedback, let alone accepting it. We identify too closely with our contribution, such that criticisms of it—no matter how valid—are taken personally and put us on the defensive.

It doesn’t help that most of us also have a hard time giving feedback, often delivering criticisms without empathy or in ways that are directed more at the person than at their contribution.

Both receiving and giving feedback are skills that can be learned and honed through practice. As you enter into this world of free and open source contributions, I encourage you to remember these tips:
You are not your contribution. Even if the person providing the feedback is unskilled at it, and their criticisms come across as personally directed, try not to take their comments in that way. Try to focus on the aspects of their feedback that relate directly to your contribution, then guide the feedback conversation toward these elements.

It’s not personal. Problems found with your contribution are not problems found with you. You’ve put a lot of time and effort into that contribution, so naturally you feel a bit attached to it and that’s OK. It’s right to feel pride in what you’ve created and accomplished. But it’s better to recognize that there’s always a way to improve your contribution. Collaborate with those providing feedback to help evolve the contribution, the project, your knowledge, and your skills.

Feedback is a gift. When people provide feedback on your contribution, they are freely sharing their knowledge and experience with you. You can use this feedback to grow into a more skilled contributor, then one day pay that gift forward as you provide feedback to others. This is part of the beneficial cycle that allows free and open source to grow.

Feedback and questions help make you better at what you do. That’s because feedback and questions help you see things you never have before and expand your mind and experiences in ways you never anticipated. None of us are perfect. None of us are all knowing. All of us have been in your position before: feeling excited at the newness but more than a little lost in it as well. It’s OK. Ask questions. Ask for feedback. It’s the only way not to feel lost, and we all want to help you.

If you get angry at some feedback, step away for a bit to cool off before responding. It happens: a piece of feedback will get under your skin. Perhaps it was the way it was phrased. Maybe it’s dismissing an implementation about which you have very strong opinions. Or maybe the person who gave the feedback is just an indelicate chowderhead. Like I said: it happens. Just because you’re angry does not mean you have to react immediately. Replying in the heat of the moment rarely ends well for anyone involved. Take some time to cool off before responding. Go for a walk. Play with your pets or your kids. Spend some time on a hobby or other project. Fire up a good movie or video game. Whatever it takes, give yourself some space from the offending comment. Once you’ve had the time to cool off and think it over some more, then you can respond rather than react.

Always Assume Good Intent. Above all, always assume good intent with all feedback. No matter how poorly a piece of feedback may be delivered, the person providing it is still giving you that gift of their knowledge and experience. They’re not (usually) doing it to show off; they want the best for the project, for the contribution, and for you. Respect that and them and help them help you provide the best contribution you can. They mean well. Do you?

Conference Call

Once in a while, it makes sense for a project community to get people together for real-time, high-bandwidth communication. While meeting in person is great for this, it’s also cost and schedule prohibitive. When you have community members distributed not only across the globe but also across the life-obligation and expendible-income strata, you can’t really bring them all to a single location so you can have some quality brainstorming time.

While time zones are still a complication (which, if you work with software, is something you should get used to), a conference call allows the distributed community members of a project to come together and share their thoughts while also getting to know their fellow contributors in a way they never could through any other communication channel.

The tool used for these calls will vary by project and also by the bandwidth requirements of the members. It may not make sense to hold a video conference if many of the community members live in a bandwidth-constrained region or must pay a great deal for data plans for their mobile devices. Therefore, you’ll usually find that conference calls for free and open source projects feature the option for voice-only participation so as to include as many of the community members as possible. Without this, it would be difficult to meet the goal of the call: to enable the community members to collaborate and discuss matters both remotely and in real time.
Conference Call Etiquette

As you can imagine, getting people together on a conference call is a fairly special event for most FOSS projects. There are a few things you can do to make sure the group is able to make the most of the limited voice-/face-time that they’ll have together during the call.

Dial into the call itself several minutes before it’s due to start. This allows you to confirm that you have the correct dial-in information with enough minutes to spare to frantically email or message people in case you don’t. If the call is using an online service of some sort, connecting a few minutes early gives you the chance to download any necessary software or updates and have everything running smoothly before the call starts.

If you’re the one organizing the call, always have an agenda for it. This lets people know what you plan to discuss so they can prepare in advance. It also lets people who aren’t interested in those topics opt out and skip the call entirely. If you’re not the one organizing the call, pay attention to the call agenda. Prepare information you might need in advance. Don’t derail the call by changing the conversation to a different topic. Doing so is disrespectful of the time of everyone else on the call, who joined expecting to discuss what’s on the agenda.

When you’re on the call, always mute your microphone unless you’re speaking. Even the tiniest background noises can disrupt a call, which wastes the time of everyone who’s participating. If you’ve joined the call audio-only, without a video component, always state your name when you start speaking: “This is Vicky. I understand what Percy is suggesting, but I have concerns…” The community probably doesn’t get the chance to get together very often, so don’t assume that they can recognize your voice.

Table of Contents
	 Preface	What’s in This Book?
	What’s NOT in This Book?
	Who Should Read This Book?
	Why Is This Book Not Openly Licensed?
	Suggestions, Errata, or Questions?

	1. The Foundations and Philosophies of Free and Open Source	It’s About the People
	Why Learn About the Philosophies?
	Free and Open Source Software Is Everywhere
	Other Open Movements
	The Origins of Free Software
	The Origins of Open Source
	Difference Between Free Software and Open Source
	An Aside About Terminology
	A Brief Introduction to Copyright and Licensing
	Types of Free and Open Source Software Licenses
	Now You Have a Strong Foundation

	2. What Free and Open Source Can Do for You	FOSS Benefits to Your Skillset
	FOSS Benefits to Your Career
	FOSS Benefits to Your Personal Network
	Benefit from Preparation

	3. Prepare to Contribute	Ways to Contribute
	Common Project and Community Roles
	Files You Should Know About Before You Start
	Issue Tracking
	Common Communication Routes
	Contributor License Agreement/Developer Certificate of Origin
	You’re Ready to Find a Project

	4. Find a Project	Set Your Goals
	Collect Your Requirements
	Collect Candidate Projects
	Select a Project
	Select a Task
	What Is “Success”?

	5. Make a Contribution	Prepare for Your Contribution
	Craft Your Contribution
	Clone and Branch
	Atomic Commits
	Test Your Contribution
	Submit Your Contribution
	Review, Revise, Collaborate
	Tidy Up
	Special Considerations for Windows-based Contributors
	There’s More to Contributing Than Just Code

	6. Make a Difference Without Making a Pull Request	Review Contributions
	Provide Testing
	Triage Issues
	Volunteer for the Less Interesting Things
	There Are So Many Options

	7. Interact with the Community	After Your First Contribution
	Get Help
	General Tips for Participating in Discussions
	The Importance of Setting Up and Maintaining Expectations
	Communication Channels and How to Use Them
	Mailing List
	Issue Tracker
	Real-Time Chat
	Conference Call
	Only the Tip of the Iceberg

	8. It’s About the People	Get Together
	Tips for Coping at a Conference or Meetup
	Form Your Own Meetup
	Moving up in the Community
	FOSS Is People

	9. When It Goes Wrong	Intimidated by FOSS’ Reputation
	Can’t Find a Project
	Company Policies
	Contribution Process Is Unclear
	Language Barriers
	Your Contribution Is Declined
	Community Problems
	Sometimes You’re the Problem
	How to Exit a Community
	You Don’t Have to Feel Trapped

	10. Start Your Own Project	Quick Start Guide to Releasing Your Own Project
	What Is Your Goal?
	Optimize for Community
	Work in the Open
	Keep It Simple, Silly
	Share the Burden Early
	Select Communication Routes
	What About Issue Tracking?
	Select a License
	How to Apply a License
	Publish the Project and You’re Done!

	11. Contribute for Your Job	Contributing to External FOSS Projects
	Contributing to Your Company’s FOSS Projects
	Convincing Your Employer to Support FOSS
	Forge Your Future

	A1. Glossary

Copyright © 2018, The Pragmatic Bookshelf.

General Tips for Participating in Discussions

Across all of the FOSS contribution process, communication is probably where the most unwritten rules hide. Over the decades, the free and open source software world has developed a lot of habits and expectations about how to communicate. Naturally, as with all other aspects of contributing, these habits and expectations vary from community to community. By now, it probably won’t surprise you that however much these things vary, there are still some guidelines that apply to most situations.

We’ll get into guidelines for specific types of communication channels in a moment, but first, there are some guidelines that apply across all forms of communication. Practicing these will help your communications be much more effective.
Listen and read more than you speak and write: A civil discussion can quickly turn heated through simple misunderstandings. Often these misunderstandings come from not taking in all of the information being presented to us. You may reply having only seen part of the whole picture, and your reply can spark flames. Take the time to read or listen to the complete set of information before you reply.

Comprehend, then act rather than react: There’s a difference between listening and hearing. When reviewing a discussion, pause to make sure you absorb it. Listen to what the other participants are trying to say; don’t simply hear their words. If you have a strong emotional reaction, either positive or negative, try to wait a bit before responding. Think your response through, including the impact that it may have on the others in the discussion. Knee-jerk reactions are rarely an effective way to collaborate with others.

Try to understand other perspectives (ask for more information if you don’t): As you’re working to comprehend the technical aspects of the discussion, take the time to consider the perspectives of the other people participating. Free and open source software is populated by brilliant people just like you, and those people rarely do anything without what they believe is a good reason (even if you don’t agree with it). If you don’t understand the perspective or reason for a suggestion, ask. A simple, “I think you’re suggesting this thing, but I’m still not clear on your reasoning. Could you please give me more information?” can avoid miscommunication and flaring tempers.

It’s not a competition: No one is keeping score in these discussions. There is no race to be the first one to have a suggestion accepted. A dialogue is not a competition, and there’s no reason to treat it as one. If you’re usually a very competitive type of person, keep that in mind while participating in the discussion and be very aware of your responses. Who are you trying to benefit with them? Are you working for the good of the project, or are you trying to “win” the discussion? Be honest with yourself, and try to craft your responses to help the project rather than draw attention or praise to yourself.

It’s not about you: Relatedly, it’s going to be pretty rare that a discussion in a free and open source project is about you, but if it is, then it’s possible something may have gone hideously awry. Aside from those rare occasions, these discussions are not personally directed and should be about matters that concern the project. If your suggestions or questions are not accepted during the discussion, it’s not an attack against your skills or worth as a human or as a contributor. It’s simply that the suggestions or questions are not accepted; don’t take it personally. If it turns out that it is an actual attack against your skills or worth as a human…well, we’ll cover that in the next chapter.

Keep it public: Above all, remember: these are public projects with distributed communities, perhaps globally so. Conversations related to the project should occur in the public space, be it issue tracker, mailing list, real-time chat, or in person. If sometimes a smaller group needs to split off to discuss a specific topic, the results of that discussion should be reported to the entire community in some way. While there are exceptions (discussions about Code of Conduct violation reports, for instance), private discussions and decisions have little place in a FOSS community or project.

Keep these guidelines in mind whenever you’re participating in discussions in free and open source communities. By using these tips, you’ll exhibit respect for the community and its members and gain a lot of respect yourself. As a respected member of the community, your contributions will gain in their effectiveness and impact, all because you took the time to learn how to communicate well.

Company Policies

As you learned in Chapter 1, ​The Foundations and Philosophies of Free and Open Source​, copyright is a complicated thing, but its concepts and those of intellectual property underlie every free and open source software project and contribution. You also learned that while sometimes you automatically have copyright over your creations, in some countries you must apply for it, and other times your employer retains copyright over anything you create while employed by them. This can be a big hurdle when you’re trying to contribute to a FOSS project, because depending on your employment agreement, the work you submit to the project may not be yours to give. Submitting a contribution over which you hold no copyright is a recipe for legal disaster for you, for the project, and for your employer.
Who Owns the Copyright?

Before you start contributing to any free and open source project, it’s imperative that you review your employment agreement first. If you can’t locate your agreement, ask your HR department for a copy. Once you have it, confirm who owns your work when it’s created in each of these situations:
	On company time and company equipment
	On company time but your own equipment
	On your own time but company equipment
	On your own time and your own equipment

Use this grid, marking in each box who owns your copyright for work created under each condition. Do you own it, or does your company?
[image: ./images/copyright_ownership.png]

If it’s unclear who owns the copyright in a certain condition, you have two options. First, you can take the safe route and assume that your employer always owns copyright to your work under that condition. You could try your luck by gambling and assuming that you retain copyright in that condition, but assuming in this direction could end up being very expensive for you. Your second option also costs money, but considerably less: take your employment agreement to a contract or employment lawyer and ask them to figure out who owns the copyright in each of the conditions in the grid. Ideally, you’ll have done this before you start your employment. That’s usually the best time to be negotiating any changes should you discover that each of the boxes in the grid come out saying, “Company owns”, but it’s sometimes possible to speak to your employer and receive permission to retain copyright over your FOSS contributions under one or more of the conditions in the grid. I’ll talk more about that in a moment.

Once you fill in the grid and have a good understanding of who owns the copyright to your work and under what conditions, speak with your manager or supervisor and let them know you would like to contribute to a FOSS project. Even if you’re contributing under a condition where you retain copyright, it’s a good idea to let your manager know so they don’t get surprised by this later. They also may not know who owns the copyright and under which condition, so it’s best to get in front of that before it becomes an issue. It could be that your manager doesn’t really care whether you contribute or not, but it’s best not to assume (especially if you hope to contribute using company time or equipment).
Getting Buy-in

When you’re speaking with your manager, ask them whether the company has an overall policy about contributing to free and open source projects. Sometimes, even if your employment agreement says otherwise, a company will allow its employees to retain copyright and contribute to certain projects. Other times a company may be OK with you contributing, but only if its done in the company’s name or from the company’s account. You’ll never know until you ask, so do take a moment to gather this information.

If it turns out that, after all of this work, there’s still no official way for you to retain copyright over your work and contribute it to a FOSS project, you may need to ask your manager whether it’s possible to get an exception to your employment agreement and/or to the company contribution policy. Before you ask for this, prepare all of the business reasons that it’s to your company’s benefit to grant this exception. They’re unlikely to do it out of the goodness of their hearts, because contributing is the right thing to do. You’ll have to prove that the company will get something out of this arrangement and that your contributions will not put them at legal risk. If you’re able to get them to grant this exception, get it in writing. Even an email confirming that you’re allowed to contribute (and under what conditions) is enough to provide some protection should situations change later. For instance, you may move to a different team, and that manager may not know that you’ve been granted an exception to contribute. It’s very helpful to have written proof of the exception so you don’t get in trouble. However, don’t rely on that exception not being rescinded in the future. Your past manager may have agreed to allow you to contribute, but your new manager may need you to spend your time in other ways.

This question of who owns the copyright to your potential contribution is particularly important when the project to which you wish to contribute has a Contributor License Agreement (CLA) or a Developer Certificate of Origin (DCO) that you must sign before your contribution will be accepted. If you recall from Chapter 3, ​Prepare to Contribute​, the CLA and DCO are legal documents used by some projects to help manage the copyright madness that can occur when multiple people hold copyrights in a single project. Each one of these documents requires that you agree that you have the legal right to provide your contribution to the project. It’s very important that you be clear about whether you actually have copyright on your contribution before you sign one of these documents. Signing when your employer actually has the copyright can lead to a lot of very expensive headaches for you, the project, and your employer, and it may even lead to you losing your job.

It may not seem like that big of a deal who owns the copyright to the work you create, but as you read above, it can matter a great deal. It’s not wise to play fast and loose with copyright law, and it’s always a good idea to err on the side of caution. If you’re not one-hundred percent sure that you have the copyright to something you wish to contribute—and if you don’t have that in writing somewhere—do not take the risk and make that contribution.

What’s in This Book?

In these pages, you’ll find everything you need to start contributing to free and open source projects. First, we’ll cover the history and philosophies of these movements, since without that knowledge, you’ll trip and fall on the very first step of your journey to becoming a contributor. After that, we’ll investigate the benefits of contributing to free and open source and help you select a project that suits your needs, so both you and the project can benefit from your contribution. Obviously we’ll cover how to make the contribution itself, but we’ll also discuss the many ways you can contribute without writing a line of code. All of those unspoken rules will be revealed, and we’ll even talk about how to start your own open source project.

Optimize for Community

Unless you are just throwing your project over the wall, you probably want to attract users and contributors to it, which is to say: you want to build a community. There are entire organizations[103][104] dedicated to helping people learn how to build communities, so I won’t cover it in detail here. However, if you’ve gotten this far into the book, you already know a lot of the elements that can help lead to a strong and effective community. Optimizing your new project for these elements can put you on the right path toward attracting users, contributors, and collaborators.

The elements necessary to optimize for community are also those that help to establish, build, and maintain the trust of other people. It’s important when implementing these elements that you remain entirely authentic and open. If you dissemble in any way, even if you think you’re very clever about it, people will know, and they will rescind any trust they had given to you and your project. Once that trust is lost, it’s difficult bordering on impossible to regain. It also undermines the project’s chances of having a good reputation, meaning you’re less likely to attract new community members. Step carefully when establishing these elements to make sure you’re not at risk of that sort of unpleasantness.

So what are these elements that can help establish, build, and maintain trust while simultaneously building community? You know them already:
An enforced Code of Conduct: Having a Code of Conduct in your project shows people that you care about their comfort, safety, and well-being, as well as for the overall health of the project. It’s a sign that the community is here to improve the project and that unprofessional or rude behavior, which would sabotage that effort, is not welcome. People know that they can make their contribution and join the community without fear of personal and unwarranted attacks based upon attributes such as gender, sexual orientation, religion, or age among others.

A CONTRIBUTING guide: A CONTRIBUTING guide is a sign that the project community understands and has anticipated the needs and difficulties of new contributors. The guide may have bugs when first launched, but that’s to be expected. Doing your best to put yourself in the mindset of a new contributor, understanding their perspective, and trying to provide the information they need shows potential contributors that you care about and respect their time.

Abundant documentation: This entire book is about contributing and contributors, but they’re not the only ones who require documentation. Most often someone is a user of the project before they become a contributor; however, if the user documentation is nearly non-existent, then no one will enjoy using the project and you’ll have lost a large pool of potential contributors. Do your best to provide a guide for how to install, use, and troubleshoot the project. If the project has an API, document that with all parameters and return values and provide sample code. If you make it easy for someone to use your project, you’ll be making it easy for them to join the community as well.

A responsive community: Users, contributors, and community members all have the same limited time availability as you. It can be quite frustrating to have a personal project put on hold because you’re waiting to hear back on a question or a contribution to a FOSS project. Respect the time of others and try to build a community culture of quick communication. That communication doesn’t have to be a detailed answer or review of a contribution, but it should at least acknowledge receipt of the question or contribution, express gratitude for it, and set up an expectation for when the sender can hope to receive a more detailed response…and then follow through on that promise. Minimizing the times when your project or community becomes a bottleneck for others helps to establish a very good reputation.

All of these tips really come down to one thing: Have empathy for others. Put yourself in their shoes and try to anticipate questions, problems, or needs they may have. This empathy creates a culture and environment that’s attractive to new users and contributors and can lead to building a community more quickly than you anticipated. It also becomes a lead-by-example sort of situation. As new community members see you being empathetic and understanding to new users, new contributors, and new community members, they themselves are likely to emulate this behavior and be empathetic and understanding themselves. Empathy becomes, simply, “the way we do things around here,” and generates a positive cycle of welcoming new members to your community.

Contributor License Agreement/Developer Certificate of Origin

A few free and open source software projects require all contributors to agree to either a Contributor License Agreement or a Developer Certificate of Origin before their contributions can be merged and distributed with the software. While the number of projects that require this is still relatively small, it’s increasing every year, as more projects join free and open source software foundations. Before you get started, it’s worth knowing about these documents and how they might impact your contributions.

Some projects—especially but not exclusively, those developed under the aegis of a large corporation—require all contributors to sign a Contributor License Agreement (CLA). A CLA is a document resplendent with intellectual property implications and therefore, a controversial matter for some free and open source software practitioners.

The contents and prescriptions vary by CLA, but basically, one exists to make sure that you (or your company, if you’re contributing on their behalf) have the right to share your contributions, agree that the project has a license to alter, distribute, and administer those contributions, and you agree that you will never revoke that license. Sometimes the document also includes a transfer of copyright from the contributor to the project or project’s organizing body. The intention of the CLA is to minimize potential legal complications of distributing the work, as well as to potentially make it easier to change license.

As mentioned, CLAs are controversial for some people and projects. Many object that the requirement to sign a CLA before making a contribution not only slows down the entire contribution process and adds administrative overhead to the process, but also discourages many people from contributing at all. Other people object to the idea of signing over their copyright to another entity (again, that’s not a feature of all CLAs).

Recently, the Developer Certificate of Origin (DCO)[55] has become a more popular alternative to CLAs. A short and simple document, the DCO ostensibly achieves the results of a CLA without the administrative overhead or related slowdown in contributions. A DCO relies upon a contributor signing their contribution using the -s or --signoff flags of the git version control system. This signing denotes that they have the right to distribute their contribution and do so under the same conditions as the project license. This means that the DCO can only be applied to contributions that can be committed to the project’s git version control system…assuming the project uses git at all. If the project uses Subversion, CVS, or another version control system, it may not be able to use the DCO. So the DCO is not the right solution for all projects nor all contributions, but some projects find it a welcome change from CLAs.

What’s NOT in This Book?

This book will not hand you a list of free and open source projects where you should start contributing. Not only would such a list be out of date the moment it was published, but it also wouldn’t be the right list for everyone. Thousands of free and open source software (FOSS) projects exist in the world today. It would be silly to list a few, then send all of you stampeding off to contribute to just those. With so many projects to choose from, you can find a project that matches your specific skills and interests. In fact, there’s an entire chapter to help you do just that.

This book also does not recommend which tools to use for contributing. The most effective tool is the one that works for you (as long as the end product meets the requirements of the project).

I’ve gone to great lengths to try not to influence your choice of project or tools, while giving you the information and support you need to make your own decisions. You do you, honey.

Select a Project

You’ve done a lot of work by this point, so the next step may not take you very long. It’s time to select a project where you can start contributing. You could do this the old fashioned way by throwing a dart at a dartboard covered in potential projects, or you could do it the smart way by comparing the list of projects you’ve built with your list of requirements. It’s possible that there won’t be a single project that meets all of the requirements on your list. That’s OK. As long as it meets some of them, you’ll still be moving toward your personal goals.

While matching your requirements is a very important feature for any potential project, it’s not the only one you should take into consideration. There’s also the matter of how easy it will be for you to contribute. This will be your first contribution, after all. Why not give yourself the best possible chance of success by choosing a project that makes contributing more straightforward? It may feel like stacking the deck in your favor…and you’d be right. But there’s nothing wrong with that, is there? If you start your free and open source software contributions with an easy win, you’ll be much more motivated to continue down the path of contributing elsewhere.

Have a look at each project on your list, starting with the documentation. Does the project have a CONTRIBUTING file or similar documentation guiding people through the contribution process? Does it have robust documentation for setting up a developer environment? Are the communication routes for the project documented and active (people who ask questions receive answers)? If so, you may have a good starter project on your hands. Next, have a look at the project’s issue tracker. Are there any open bugs or features that you think you might be able to tackle? Maybe some of them are tagged as Help Wanted, First Timers Only, Newbie, Good First Issue, Up For Grabs, or some similar flag to highlight them for people like you.

It’s certainly not required that a project do all of these things. Thousands of very good projects are out there, supported by healthy communities, that do not meet all of the criteria in the preceding paragraph. However, if you find a project that has implemented even one of those criteria, you’ll find that it will make your first time contribution experience much more pleasant than contributing to a project that has not.

Once you’ve reviewed all of the projects on your list for how easy they may be to contribute to, your choice of starter project may now be obvious to you. If it’s not, don’t worry. For some people, it’s better to explicitly list the pros and cons for each project, then analyze and review them all together this way. There’s no right or wrong method for coming to your decision. Do what’s best for you and the way your brain works.

Remember, though: when you decide on a starter project, that decision is not carved in stone. You may find that the community is not as welcoming as you hoped, or once you start contributing, you aren’t getting what you need out of it. If that’s the case, it’s perfectly OK to stop contributing there and find another project where you can devote your time. I caution you, though: before you quit, consider whether you might be the problem. In your zeal to contribute, it may be that you’re not doing as good of a job as you could in communicating or understanding the contribution process. Ask the project community for feedback, help, and mentoring (just don’t expect to be spoon-fed). If these things aren’t forthcoming or don’t help you feel more comfortable with the project, don’t hesitate to move on to something that is a better fit for you.

Community Problems

People, as I’ve already pointed out, are very complex, difficult, squishy things. Because communities are composed of people, they are similarly complex, difficult, and squishy. These factors contribute to communities exhibiting a lot of problems that, really, are common across most human endeavors. There are no perfect communities; there are only communities that recognize there are problems and work to fix them and communities that trundle along blissfully ignorant of their issues.

No matter which of these two types of communities you join, you’re guaranteed to come up against problems that are based in human interactions and community culture. Often it’s possible to work around these issues; once in a while it’s possible to apply commitment and empathy to help fix them, and sometimes you may decide either just to deal with the problems or to leave the community and its problems in your rearview mirror. Which approach you take is entirely up to you, but it’s important to emphasize that you do have a choice. At no point should you feel obligated to deal with or fix a community’s problems. If you find that the community situation is uncomfortable to you, feel free to leave the community for a different one.
Unresponsive Community

One of the problems you may experience is that the community is completely unresponsive. You’ll spend several very valuable hours creating a contribution, submit it to the project, and then…nothing. The community members never get around to reviewing your contribution, let alone acknowledging or accepting it. It’s as though you tossed your contribution into a black hole, never to be heard from again. Other times they may respond, but it will take them weeks or months to do so.

There are plenty of reasons why a community may not be quick to engage with you, and none of them have anything to do with you personally or with the quality of your contribution. For one thing, there may not be very many people in the community. The fewer people there are to maintain the project, the more time it may take for any one of those people to review contributions as well as to submit their own. Each of those community members, no matter how many of them there are, is also busy trying to maintain their own life and the many complexities that come with that. Adding FOSS project maintenance on top of that is a burden that leads many community members to burn out and pay less attention to the project. This itself can lead to a project falling out of active maintenance. Any of these factors may contribute to a slow (or non-existent) response time when you submit a contribution or even simply a question to a project.

So what can you do about it? Before you submit your contribution, you can try to get a community member to acknowledge it and give you an estimation for when you might expect a review of some sort. This acknowledgment is usually easiest to get by email, real-time chat, or the issue tracker at the time when you’re confirming that you understand the issue or that the project needs your contribution. Doing this up front before you even submit your contribution can help set up expectations on both the submitting and receiving sides of the relationship and can help smooth the entire process.

After submitting your contribution, you can gently prod people to remind them that a contribution is sitting there awaiting review. How long you wait to do this prodding will depend upon your needs, the project community’s usual turnaround time, and other factors that vary from situation to situation. Typically it’s polite to wait at least a week before giving the maintainers a nudge to see whether they’ve seen your contribution. However long you wait, do be polite when asking people to take time out of their day to review. You’re unlikely to get the response you want if you’re a jerk to the people whom you want to accept your contribution.

If weeks pass without hearing from the community, and if no other activity is happening on the project, it’s possible that the project has fallen dormant for one reason or another. There are two options you can take here, but both of them may require a lot of work on your part. The first option is to try to contact the community and ask whether you can take over as lead maintainer of the project. This can breathe new life into a project, particularly when the existing maintainers are too busy or burned out. However, it’s important to recognize that the project you’re asking to take over is the one that contributed to that burnout. Think carefully before you take on that burden to make sure that you can bear it.

The second option is to fork the project, then use your fork instead of the original project: you create a separate copy of the project (a fork) and make whatever changes you need without having to wait for anyone to approve your contributions[100]. When you fork a project, there’s no requirement to contribute your changes back to the original project as shown in the figure.
[image: ./images/forking_project.png]

You might be thinking, “Great! I’ll just do that and then I don’t have to deal with those slow losers who won’t acknowledge my contribution!” And, sure, that’s one way to look at it. However, forking a project should be a last resort. It is almost always better to work upstream (on the original project) than it is to fork it to create your own version. If the project is still under active development, then it can be a great deal of work to keep your project in sync with upstream. Without this work, you’re likely to miss vital bug and security fixes, as well as features that will make the project more useful.

Note as well that while some code forges like GitHub use the work “fork” as equivalent to a simple git clone of a repository[101], in this case, forking is a social move and can be seen as a hostile move by the original project’s community. It can come across as you saying, “You’re not doing a good enough job. I’m going to create my own project based on yours and build a better project and community, so there, take that.” If you absolutely must fork a project, be careful how you approach it so you don’t unintentionally cause offense. It’s far preferable to try to work with the community on the upstream project than create your own copy for your own personal use.

Overly Responsive Community

Once in a while rather than silent communities, you’ll experience the other side of the communication coin: people just won’t shut up about your contribution. Too many people communicating at once can be just as frustrating as no communication at all. In the case of an overly responsive community, you’ll end up with far too many cooks in the kitchen. Each contribution received will have a host of people chiming in with feedback, each asking for their own preferred changes, and potentially each with differing opinions. This over-abundance of communication can make it impossible to get project maintainer approval for your contribution as you try to reconcile conflicting viewpoints.

While not always the case, an overly responsive community can sometimes be a sign that the project community is experiencing political problems or has little guidance or direction. Rather than collaborating to move the project in a single, agreed-upon trajectory, the contribution reviewers are each attempting to futher their own agenda or build support from other community members. Your contribution, unfortunately, is caught in the middle.

What do you do about the case of an overly responsive community? First ask yourself whether it appears they’re aware of the problem. It may just be that there are no politics at play, and everyone is just trying very hard to be helpful in their own special way. Politics or not, the community may not realize that they’re giving you conflicting information, overloading you with perspectives, or otherwise making it difficult for you to complete work on the contribution so it’s ready for acceptance by the project. If this is the case, politely point out that you’re getting conflicting information and ask them which way they would like you to go with it. When doing this, it can be helpful to summarize all of the perspectives. Often listing these in a single spot can show the reviewers how silly things may have gotten. For example:

Hello! I appreciate all of your help and feedback, but I’m
having a hard time reconciling some of the changes folks are
asking for. Could someone please prioritize these requests
or otherwise help me make sense of them?
	Make the buttons blue to match the logo
	Make the buttons the green accent color
	Remove the buttons in favor of links
	Merge this login page with registration and use those buttons

Thanks for any help you can give me!

After studying the community, you may decide that this sort of consensus building isn’t going to do the trick because matters are too chaotic or politically charged. There are a few other options you could try in this case. You could judge for yourself which is the most popular or prevailing opinion and focus on satisfying just it. Beware that this may have the effect of taking sides should there be a political struggle brewing, so make sure you’re comfortable supporting the associated (or any) political agenda before deciding to go this route. Another option is to speak with a core contributor, pointing out the conflicting viewpoints you’re receiving, and ask them to arbitrate the matter. Depending upon the project, the contribution, the conflict, and the overall situation, you may even wish to ask a core contributor to collaborate with you directly. This can help shield you from some of the politics and chaos and potentially speed up the process of accepting your contribution.

Unfocused Community

Do you know someone (or maybe you are someone) who can’t seem to finish anything? They’re constantly starting something new—new projects, new hobbies, new thoughts—but never actually seeing them through to the end. Some projects are like this as well. Lacking strong leadership or even a basic project roadmap, the community finds itself constantly shifting gears from one feature or initiative to another. There may be priorities, but they change frequently, and that change takes with it the time and energy that had been devoted to the previous “top” priority. People may be contributing a lot of work, but none of it is leading anywhere. For instance, the community may spend two months focusing its efforts on translating the user interface, only to set that work aside uncompleted as it changes course to focus instead on adding single-sign-on functionality. If your contribution is a part of that translation initiative, then when those gears shift, you may find yourself with a dormant contribution on your hands. It may be accepted, but it may never be used if the initiative isn’t completed. This can be a problem if you need that initiative or your contribution released so you can use it at work or in one of your own projects.

When a community and a project lack focus, one way to handle it is to try to add a little on your own. It may be possible to gather collaborators from the community to complete the necessary initiative, or even to do so on your own if you have the skills and experience needed. By focusing your own efforts on a single piece of the project like this, you may be able to lead by example. As others notice, it might become possible to evolve the project toward one that’s more focused and more likely to complete initiatives rather than abandon them for the next big thing. This will probably involve developing a project roadmap and/or a release cycle, and it will require project management and negotiation skills. Most importantly, it will require a large commitment in time and patience from you. This sort of change effort cannot be rushed if it’s to be successful.

If you don’t have the time (or patience) to lead or participate in the effort to evolve the project toward one that’s more focused, your only other options are to become comfortable with the chaos and learn to work within the project’s shifting tides of priorities, fork the project as described above, or leave that project in favor of another where your time and contribution will make a more immediate and positive impact.

Community Politics

As you probably gathered from the Overly Responsive Community section, free and open source software project communities can sometimes be politically charged. Frankly, any undertaking involving two or more humans can be politically charged, but FOSS maintainers, contributors, and users can be a particularly passionate bunch. That passion often leads to conflict, and the conflict can lead to politics or other complications. It’s very true that not all politics is bad. Humans are, after all, political creatures, and we’ve done a lot of amazing things because of it. However, you all are probably also familiar with some of the less pleasant things that politics can cause in the world. FOSS project communities are no different and sometimes can suffer from the ugly type of politics.

The most common form of negative politics will be in-fighting between factions in a single project. This faction has one opinion, that faction has another, the faction over there…well, it’s not clear what their opinion is, but they’re against what the other two factions are trying to do. Another common form of FOSS politics is empire building by ambitious community members. For some people, being seen and acknowledged as important is a priority in their lives, as is amassing power. Even the small amount of power found in a FOSS project—such as setting a roadmap or approving changes—can lead some people to manipulate others and use both contributors and contributions as pawns to further their agenda.

When you join a project and discover that it chronically suffers from negative politics, you can of course try to stay out of it. You can send in your contributions, review submissions, and answer questions without picking a side. This can be very difficult, but it’s possible. It’s usually easier to evaluate the situation and then align yourself with a certain faction, but depending upon the situation, that may not be a desirable option either. If you find you can’t participate in a project without also being a part of its community politics, but you don’t wish to get involved in those politics, then your best option may be to withdraw from the community and go find one with less (or perhaps a different type of) political turmoil.

Rude Community Members

As I mentioned at the start of the chapter, free and open source software does not always have the rosiest of reputations. While part of that negative reputation comes from how difficult it is to contribute to some projects, the overwhelming majority of it comes from the fact that over the years FOSS has, does, and will play host to a lot of people popularly known as assholes. Some of you may object to the use of this word and its derivatives, and to you I apologize, but I will not change my vocabulary here. These people and their attitudes cause immeasurable damage, and I will not diminish that by softening my language. In this book, I will not hesitate to call an asshole an asshole. To do otherwise would trivialize how harmful they are to communities.

You’ll find folks like this wherever people gather, but the less structured nature of free and open source software is fertile ground for these unsavory people. Without a central authority, common and documented guidelines for behavior, or a shared framework for dealing with unwelcoming behavior, these assholes feel justified in throwing the Golden Rule away and practicing their assholery with wild abandon.

This assholery takes many forms, but all of them act to make community members—and especially new contributors—feel unwelcome and uncomfortable, even when the actions are not directed at any particular individual. Some of the many different forms of assholery you may witness include:
Ad hominem feedback that speaks to the person (“you’re stupid”) rather than to the contribution (“this isn’t a good idea”)

Unnecessary negativity in reviews, feedback, and discussions

Tearing down other people for no reason beyond entertainment value

“Punching down,” also known as attacking people that are lower in the community hierarchy

If this sort of behavior makes people feel uncomfortable and unwelcome, why don’t communities do something about it? After all, a community is what it tolerates, so if that community tolerates assholes… Many communities have existed in this uncomfortable, unwelcome state for so long that it’s become normal for them. They’re no longer aware that this state is a problem, because it’s simply “the way we do things around here.” Some members of the community may be aware that there’s a problem, but are unable to get the rest of the community to agree that it’s something that they need to address. If they are able to gain consensus that something is terribly broken in their community, they then hit the roadblock of being unable to reach a similar consensus as to what to do to fix things.

Throughout this awareness-finding and consensus-seeking, the assholes are there too. While not always the case, often these people have risen to positions of power within the community. This position of power frequently has the effect of amplifying their unpleasantness as their position increases their confidence that they can do and say whatever they wish without repercussions. “They can’t get rid of me,” they think, “I’m far too important.” Whether in a position of power or not, assholes are usually the loudest voices in the conversations about what to do about them. They are often clever individuals and are able to use rhetorical tricks to prevent the community from reaching consensus or taking action. These people turn the already difficult problem of community culture change into a nearly insurmountable task.

So what do you do when you come across a community like this, where certain bad apples truly do spoil the lot? If no one is correcting this behavior, or if the community does not have or enforce a Code of Conduct, the easiest thing you can do is to get out; withdraw from the community and go find one where assholes and assholery are not tolerated. As a new contributor, you’re unlikely to have the power and influence to change a community that tolerates behavior like this.

The good news is that while there may be a bad apple in nearly every community, more and more communities are both implementing and enforcing Codes of Conduct. They don’t tolerate assholes in their community, and they’re doing something about it. There are plenty of projects of this sort where you’ll be welcomed and your expertise and time will be respected.

How to Tell (Before You Join) That There May Be Community Problems

All that talk of assholes and assholery may be discouraging, but like I said, there are loads of projects that don’t put up with that crap and where you can participate without fear of being treated poorly. How do you find them, though? How can you tell, without participating in the project, whether it’s a good one or not?

Step one is to see whether the project has a Code of Conduct. If you remember from Chapter 3, ​Prepare to Contribute​, a Code of Conduct (CoC) documents the types of behavior that are both welcome and unwelcome in that project community, the consequences for unwelcome behavior, and where and how community members can report it. While a project having a CoC is not a guarantee that it’ll be a welcoming and safe space for contributing to FOSS, it’s a very encouraging sign. Alternatively, communities that don’t have a CoC, or where the conversation about implementing one is very contentious, may be harboring and tolerating assholes. If a project doesn’t have a Code of Conduct, be on your guard when joining the community.

Step two is to do your research and see for yourself how community members treat people. Review conversations on issues, skim the mailing list, lurk on their real-time chat system. These will give you an excellent view into how the project maintainers communicate and whether they tolerate unwelcoming behavior. You can see whether people are mean, impatient, or snarky when they respond to questions from others, or whether they’re prone to ad hominem attacks or comments. You also can see whether community members respond to questions at all. While not responding may not be a sign that the community is unwelcoming, it’s certainly not a sign that you’re likely to get much help with your new contribution, either.

Step three is to ask around. If you know other people who participate in free and open source software, check with them to see whether they know anything about that community. You can learn a great deal about a community just by asking others what they’ve heard about it, even if only through the grapevine.
 Problematic communities get reputations, and often there’s a whisper network that warns people away from the bad ones.

As you do this research, you may find that you’re not very comfortable with what you learn about the community you’d planned to join. If that’s the case, carefully consider whether you should still follow through on that plan or look for a more welcoming and less frustrating project to which to contribute. You pay for your FOSS contributions with your time, and that’s the most valuable thing you have. Once you spend it, you never get more, so invest some of that time in discovering whether a community will treat you with respect. It’s perfectly OK to change plans and take your skills and time to another project, one that will appreciate and respect you. You have the power to choose. Use it.

The Origins of Open Source

The free software movement grew in popularity and awareness throughout the 1980s and 1990s and attracted the attention of business interests. The release of the Netscape web browser as free software in 1998 amplified this attention. While businesses were intrigued by the potential of open software development, many were less thrilled with the strong political, philosophical, and activist nature of the free software movement and its supporters.

In early 1998, soon after the release of the Netscape code, several free software supporters gathered to discuss how the movement might make itself more palatable to business interests, in hopes of increasing the scope, reach, and contributors for open software development. They decided a rebranding was in order and chose the term open source—coined by Christine Peterson[29]—as the name for this version of the movement. Many members of the group then created the Open Source Initiative (OSI)[30] as a focal point for their efforts.

One of the first tasks of OSI was codifying what it means to be an open source software project. The Open Source Definition describes the ten responsibilities and requirements a project must fulfill if it wants to qualify as an “open source” project. The OSI has a detailed description of the definition on its website,[31] but the definition can be summarized as:
	The project must be freely redistributable—even if sold and even if it’s part of a larger collection of software.
	All source code must be available and distributable.
	Modifications and derived works must be allowed and distributable under the same license terms.
	If distribution of modified code isn’t allowed, it cannot prevent distribution of patch files (snippets of source code that can be applied to include new fixes or functionality) along with the unmodified code.
	In no way can the license under which the code is distributed discriminate against any person or group. All people must be allowed to use the code on the same terms, even if they’re bad people like Nazis.
	Similarly, the license also can’t single out industries, companies, or other types of undertakings. All groups and ventures must be allowed to use the code on the same terms, even if those groups support horrible things (again, like Nazis).
	The license applies to anyone who receives a copy of the software without needing any additional permissions.
	The license can’t restrict someone from extracting the project or code from a larger collection. If they do extract it, it’s available to them under the same license terms as the whole, larger collection.
	If the software is distributed as part of a larger collection of code, the license can’t put any restrictions or requirements on that other code.
	The license applies to all technology and UI applications of the software to which it’s applied.

The OSI provides an annotated version[32] of the Open Source Definition. This version is valuable for understanding the meaning and importance of the definition. It details rationales and supporting information for each of the criteria for a project to qualify as “open source.”

Most of these criteria apply to the license under which a project is distributed. To aid people in selecting a license that meets all of the criteria, OSI reviews licenses and maintains a list of OSI-approved open source licenses.[33] If a project claims to be “open source” but is not released under an OSI-approved license, then the project cannot call itself “open source.”

This focus on license is a critical part of free and open source software. It’s the license and its directives that make a piece of software open source, not merely the availability of the source code. Without the application of an OSI-approved license, code can be at best “source available” but not open. The legal mandates contained in the license ensure that the code is available and that people are free to do with it what they wish (within the constraints of the license). Code and projects that do not have license files, even if they have been bequeathed to the public domain, are not open source.

Forge Your Future with Open Source

Build Your Skills. Build Your Network. Build the Future of Technology.

by VM (Vicky) Brasseur

Version: P1.0 (October 2018)

Real-Time Chat

Internet Relay Chat (IRC)[97] was invented in 1988 by Jarkko Oikarinen, and real-time online chat has been a cornerstone of free and open source software communities ever since. While IRC was probably the first chat system used by FOSS communities—and is still very popular—it’s far from the only option available. Mattermost, Matrix, Rocketchat, gitter, Zulip, and are a few of the many chat options used by free and open source projects.

Real-time chat enables…well, it enables chatting with people in real time (no big surprise there). Despite that, chat is actually both synchronous and asynchronous in nature. While you can use chat to have very involved real-time conversations with someone on the other side of the world, you also can leave messages to which others can reply later when they’re available. This dual nature of real-time chat makes it a very powerful and flexible tool for coordinating a community of people distributed across time zones and schedules.

The synchronous-asynchronous duality of real-time chat means that it can be hard to tell whether or when someone will be available for a conversation. The “real-time” in “real-time chat” is somewhat deceiving, since in the case of free and open source community chat systems, it’s usually safest to assume that all conversations will be asynchronous. You never know when someone has to step away from chat to take a call, a meeting, or their child to school. Often they’ll be in a far flung time zone from you, so you may have a question while they’re sleeping soundly in their bed. None of this means you can’t still start the conversation and leave it there in the chatroom, ready for them to see when they return. Simply mention their chat username in your message, and it’ll notify them so they won’t miss it.

As I mentioned in Chapter 3, ​Prepare to Contribute​, the selection and use of a real-time chat system has taken on nearly religious significance in some free and open source software communities of late. Respect the chat option that your community has selected and do not start a contentious discussion by suggesting they switch to another, unless you have a very good reason for doing so. Rest assured that no matter what chat system is in use by the projects in which you participate, a great deal of conversation (and possibly arguments) went into its selection and maintenance.
How to Use Real-Time Chat Effectively

You may think you’re familiar with how to use a chat system, but there are a number of points of chat etiquette that FOSS project communities have developed over the years, and they may not match what you’re used to with other chat systems.

If the chat system in use offers multiple chatrooms or channels for the project, pay attention to the topic of each chatroom and stick to that topic during all of your conversations in that room. Off-topic conversations can make it difficult for people to keep track of the important conversations going on in that chatroom, so if you must have an off-topic conversation, move it to a different room or channel.

Some chat systems such as IRC feature the ability to include URLs in the topic for a chatroom or channel. If a topic contains URLs, click through and read those pages. These typically point to documents relevant to the chatroom, including documents for discussion, rules for engaging on the chatroom, or the Code of Conduct for the project. Disregarding these URLs may lead you to violate chatroom policy and may get you kicked out.

The first time you enter a chatroom or channel for a FOSS project, take time to lurk silently before you participate in discussions. In a chatroom context, lurking means joining the chatroom and reading what’s said there but not participating in the conversation yourself. This quiet observation will allow you to get a sense of the chatroom culture, its mores, and its interaction styles. Think of it as getting to know the language when you visit a foreign land. Even a little bit of effort to learn how the locals communicate enables you to navigate the environment more easily.

It’s common for the first chatroom messages from people new to free and open source to be something like, “May I ask a question?” To most of us, this is simply being polite, the chatroom equivalent of raising your hand to speak in class. For experienced FOSS chatroom or channel members, your polite question is unnecessary noise. The purpose of chatrooms is to encourage questions and dialogue around them, so the permission to ask a question is assumed and therefore unnecessary. The phrase you may see used is, “Don’t ask to ask; just ask.” In other words, rather than politely asking for permission to ask your question, simply politely ask your question instead.

Because of the synchronous-asynchronous duality I mentioned earlier, chats will continue even when you’re not around. Those accumulated chats are known as the scrollback. Depending upon the chatroom and the conversations, scrollback can sometimes reach several hundred lines or more in length. You’re not obligated to read all of that scrollback if you don’t wish. You may miss something, yes, but if there’s something important for you specifically in there, then someone will have mentioned you in that message. This mention, also known as a ping, typically notifies you that you have a message waiting. Most real-time chat clients have a way for you to jump directly to your mention in the scrollback, so you don’t necessarily have to go through all of it to find the relevant parts. However, you may find you need to read the scrollback anyway so you can get the context of the conversation.

When engaging in a discussion in a chatroom or channel, use complete sentences and spell out words rather than use abbreviations or “text speak.” Also, try to use as good of grammar as you can, including correct capitalization and punctuation (it’s OK; none of us are perfect on this front). Real-time chat is a textual communication channel, and the people sharing the chatroom or channel with you may not understand you well or respect your input if it doesn’t appear that you even tried to construct it to be as readable and as understandable as possible. It’s also likely that their primary written language is not the same as that used in the chatroom. Using poor grammar or abbreviations makes it difficult if not impossible for these valuable people to help answer your questions.

While we’re on the subject of how to format your communications in a chatroom, PLEASE DO NOT USE ALL CAPS UNLESS YOU INTEND YOUR WORDS TO BE SEEN AS SHOUTING. We all need to yell from time to time, but try to keep it to a minimum. You don’t want to become known as that mean shouty person.

Above all, when engaging in discussions on a FOSS real-time chat system, be patient. The community members of the project are most likely all volunteers, each with their own life and obligations outside of the project. A large percentage of them may even be in completely different time zones from you, such that your waking time is while they’re fast asleep. Ask your question, then if you must, wait several hours for someone’s schedule and life obligations to allow them to check the chatroom and reply to you. If after several hours, you still have not heard from anyone, ask your question again. If you still don’t hear from someone in a few hours, it could be that the chatroom is not the best way to communicate with the members of that community. Check the CONTRIBUTING or README files for other communication channels for the project.

Intimidated by FOSS’ Reputation

The first roadblock you may face is that you may not feel up to contributing at all. Across its decades of life, FOSS has developed a bit of a reputation: It’s difficult to contribute. You won’t receive help even if you ask. The community members are unfriendly, judgmental, and unwelcoming. There’s a pervasive attitude of “suck it up, buttercup, we did it the hard way and so should you.” Community members are aggressive and insulting when faced with opposing opinions or imperfect contributions. The only way to thrive in FOSS is by having a thick skin and by “looking out for number one.”

This is the reputation, and I’m sorry to report that it’s based in reality. All of the bad characteristics I listed have occurred in free and open source software communities and undoubtedly will occur again. As you learned in Chapter 8, ​It’s About the People​, FOSS is composed of people. As you’ve learned across your entire life, people can be difficult, complicated, squishy, and downright unpleasant at times. Therefore, any endeavor that involves people (so…you know…all endeavors) has the potential itself to become difficult, complicated, squishy, and downright unpleasant. FOSS is no exception.

It’s true that many free and open source software communities have and do tolerate the sort of behavior that leads to all that unpleasantness, but it’s unfair to paint all of FOSS with that ugly brush. Remember that academic study [BBFV01] I referenced back in Chapter 6, ​Make a Difference Without Making a Pull Request​? The one that shows that humans are more likely to focus on the negative than the positive? That same tendency is at play here. The overwhelming majority of FOSS project communities are helpful, supportive, welcoming, and grateful for their contributors, yet the few communities that tolerate negative behaviors become the bad apples that spoil the entire barrel and contribute more heavily to the overall reputation of free and open source software communities. Most communities, however, recognize that it’s a bad idea to be jerks to other people and discourage and guard against the sort of behavior that’s led to the poor reputation FOSS has gained over the years.

So, yes, there are FOSS communities that are nasty, brutish, and short-tempered. Overall though, you’ll find that communities are composed of people just like you: normal folks just trying to improve the project and make a difference in their own small, yet significant ways. Don’t be scared off by the poor reputation of free and open source software communities and be encouraged by the fact that your contribution is needed and valuable. If in your FOSS explorations, you discover a community that tolerates negative behaviors, the most effective thing you can do is to get out of there. You don’t deserve to be treated that way, and they don’t deserve your time, loyalty, or contribution if they think it’s OK for their community members to be jerks.

Types of Free and Open Source Software Licenses

The best place to learn about the various types of free and open source software licenses is the Open Source Initiative Licenses list.[36] It can be a little overwhelming at first, so to get you started, here’s a quick introduction to the two basic types of FOSS licenses: copyleft and permissive.

Per the Open Source Definition, mentioned in ​The Origins of Open Source​, both types of licenses share the requirement that anyone who uses works licensed under one of them must be able to view, modify, and share the source of the work. The difference comes after that: What can the user then do with the work? Can they change the terms under which people can use it? Or must the work be redistributed under the same terms by which the user received the original work?

For software distributed under a permissive license, someone who makes a change and redistributes the software is permitted to change the terms and conditions under which someone can use the new distribution (also known as a derivative work). In other words, the creator may change the license of the derivative work to one that’s different from the original work. This affords the person releasing the new distribution a lot of flexibility in defining how the derivative work may be used. Permissive licenses also allow a creator to use a work released under this type of license in a proprietary work. When that proprietary work is released, it can remain proprietary. The permissive license of its component(s) does not force the creator to release the work under any sort of free or open source license. Two popular permissive licenses are the Apache License[37] and the MIT License.[38]

While permissive licenses allow a creator a lot of flexibility when distributing a derivative work, copyleft—or reciprocal—licenses protect a work from being relicensed under what may end up being a more restrictive set of terms and conditions. Once a work has been released under a copyleft license, the license ensures that the work can never be released under a license that may in any way remove or diminish any of the original rights and freedoms (specifically, the Four Freedoms mentioned in ​The Origins of Free Software​) granted to the user by the license. A redistributed or derivative work released under a copyleft license must also not add new restrictions to what the user may do with the work. This ensures that this work, once freed, will forever be free. Copyleft licenses also have a requirement that any derivative works made from software licensed under one of them and distributed must be released under the same terms and conditions as the copyleft-licensed work. This is the reciprocal nature of this type of license: if your creation benefits from a copyleft licensed work, then anyone who receives your creation must similarly benefit from your work. The GNU General Public License (GPL)[39] is the most common copyleft license. Other copyleft licenses include the GNU Lesser General Public License (LGPL)[40] and the Mozilla Public License.[41]

It probably won’t surprise you to hear that, as with every other legal issue discussed in this book, what you’ve just read is an oversimplification of how these two different types of licenses actually work. Each type contains licenses that are more or less permissive and more or less reciprocal. Generally speaking, of the OSI-approved licenses, the MIT License is considered the most permissive and the GPL one of the most reciprocal. All other licenses fall somewhere along the spectrum between these two.

Share the Burden Early

It’s becoming more common now to hear stories of FOSS maintainers burning out and walking away from their projects. This isn’t a new phenomenon; for as long as there have been free and open source projects, maintainers have been burning out on them. What’s new is that people are recognizing that burnout is bad, that they don’t have to put up with it, and that if they share their stories, they may help inspire others not to burn out like they did.

Now—as you prepare to release your project—is a good time to start thinking about how to prevent or minimize your own burnout as its maintainer. Much of the advice in this chapter will help with that, as it will reduce some of the burden you’ll have in answering questions of users and new contributors. Setting up your own boundaries is also very helpful, as is sharing what those boundaries are. For instance, if you can only spare a few hours every other weekend, include that information in the CONTRIBUTING file to set up expectations for when they might hear from you.

While documentation, boundaries, and other types of expectation setting will go a long way toward avoiding burnout, nothing makes as large of a difference as having other people to help you. By sharing the burden of project maintenance, you reduce the impact on any one person while improving the project’s bus factor and therefore, also its longevity and resilience. As early as possible, look for contributors who communicate well, provide quality contributions, participate in discussions, and are generally engaged with the community. Then ask these people whether they would like to become a co-maintainer of the project. You’ll naturally have to sort out exactly what “co-maintenance” looks like for your particular project, in collaboration with your new partner. This may take a few conversations or email threads to get right, but once you’ve all figured out the details, make sure to document them in the project. This sharing of the collaboration and the role that each maintainer plays in the project is part of what makes FOSS such a powerful movement and development philosophy. Open is better.

The Foundations and Philosophies of Free and Open Source

When we think or talk about free and open source software, there’s a strong tendency to focus on that last bit: the software. Software, as we all know, is just made out of code, right? So isn’t free and open source software, therefore, all about the code? It’s all programming, but it’s programming that anyone can use, like, for FREE, man. After all, that’s what the free means in “free and open source”, right? You can use it, but there’s no cost. Yup, that’s open source. Book done. We can all move along.

You’ve probably already guessed that the previous paragraph was a steaming pile of misinformation. Unfortunately, it’s based on a lot of the common misconceptions about free and open source software. These fallacies are repeated and perpetuated to the point of being seen as common knowledge. As is often the case with things like this, not everything that is common qualifies as knowledge.

Get Help

As you’re chipping away at your contribution, you’ll probably hit a few snags and will need assistance to continue. Sometimes you have the resources available to help yourself, and nearly every free and open source project assumes that you’ll try this avenue first before asking someone for assistance. In the tech industry, this is known as RTFM: Read The F’ing Manual. I’ll leave it to you to choose which word to use for the F.

The manual in question is generally defined as any sort of documentation that the project makes available. This could be user docs, installation docs, developer docs, the contributing guide, styleguides, or any number of other types of documentation. You may find that most documentation in free and open source projects needs a lot of work to be as useful as you’d like. It takes a lot of time and effort to develop documentation, so unfortunately, it’s often overlooked by the project developers. Even if your project of choice is very sparsely documented, take the time to read the docs that do exist before asking for assistance. If nothing else, the docs will provide more context so you can better understand not only the answer you’ll receive, but also how to ask your question more effectively in the first place.

Another great place to look for information about any problems you have is the project’s communication archive. If the project has a mailing list, it will be particularly helpful. Nearly every mailing list archive is both viewable and searchable online, which makes researching your problem much easier. Often the hardest part is locating the archives at all. If you subscribed to the mailing list, you’ll often find a link to the archive in the footer of messages you received. If you don’t see it there, dig up the confirmation email you received when you subscribed. That typically includes a link to the interface where you can maintain your subscription and usually also includes a way to view the list archives. If the project uses real-time chat (IRC, for instance), it may log and archive conversations from the chat system. If these logs exist, they will be either linked in the topic or subject of the chat system or documented somewhere. Searching all of these archives may lead to the answer to your problem.

You can also learn a lot from past contributions to the project. If you have a local clone of the project’s repository, you can use the version control system to search the past commits. If the project uses a forge like GitLab, GitHub, or BitBucket, it can be very easy to search all past commit logs as well as closed issues (sometimes all at once). These searches can turn up valuable information about previous problems people have faced and point you toward potential fixes.
How to Ask a Question

If after all of your reading and searching, you still haven’t overcome your roadblock, don’t hesitate to ask the community for help. Asking, however, should be done properly. No matter how frustrated you may feel, don’t blurt out an irritated question in the chatroom or on the mailing list. If you come across as unfriendly, you can expect to receive very little help. No one wants to donate their time to help a grump. There are five steps to asking a good question of a free and open source project community:
	Verify you’re asking in the appropriate venue. Some projects want you to ask on the mailing list. Others in the issue tracker. Still others in the chatroom or by some other mechanism. Make sure to review the CONTRIBUTING file to verify the correct way to ask questions for that project.
	Drop the attitude. Even if you’ve contributed to other projects before, even if you’ve been in software development for thirty years, even if you’re Linus Torvalds[92], Larry Wall[93], and Tim Berners-Lee[94] all rolled into one: Get over yourself. It’s entirely possible to phrase a question that is confident and competent yet does not make you sound like an arrogant twit. For instance, when asking about a programming optimization, rather than pointing out that you have a PhD in computer science and have been programming in that language for twelve years (information which is irrelevant to the suggestion at hand), simply state the problem you’ve noticed, how the code could be improved, and ask whether anyone would have a problem with you making the change. Take the time to craft your question accordingly. Run a draft past a friend just to be sure you don’t come across as a conceited jerk.
	Always be polite. Again, no matter how frustrated you may feel, be polite when asking your question of the community. It’s OK to let your exasperation come through, as long as you don’t direct it toward the project or the community. “I’ve read all the docs and the mailing list and tried everything I could think of, but it still doesn’t work,” is an entirely acceptable statement. “These docs are useless, the code is a mess, and the error messages are horrible,” is a statement that—no matter how true it may be—is unlikely to win you any friends. Say please and thank you and make sure that your words express only the problem and not any directed negativity.
	Succinctly but clearly state your problem. State what you are trying to accomplish, what you are experiencing instead, and the full text of any error messages you see. Be brief, but make sure to include all relevant details. If you have a log file or stack trace, drop it into a pastebin[95] or similar service, then provide a link to it in your question. It can be helpful to summarize the steps you took to troubleshoot the problem, as well as any research you’ve done. This will allow people to suggest new solutions rather than those you’ve already tried.
	Be patient. Remember: nearly every member of a free and open source software community is a volunteer. Each will have their own life and all of the complexities that accompany it. Give them a few days to reply to your question before you ping to ask whether anyone saw it. While you’re waiting, you could help the entire community by documenting anything you learned in your research while troubleshooting your problem (such as error messages and what they mean).

Interact with the Community

You’ve overcome all the roadblocks in your way, you’ve followed all instructions to the letter, and you’ve finally submitted your first contribution.


In free and open source software, the only feeling more amazing than making your first contribution is having it accepted as part of the project. When and how does that happen? You probably won’t be surprised to hear the answer is, “It Depends.” It’ll depend on the project itself, your contribution, whether anyone is available to review your contribution, and any number of other vague and mysterious variables.

Mailing List

Most projects use a mailing list (listserv) of some variety. Very large projects use multiple mailing lists, depending upon their needs. They may have one for overall development of the project, another for user support, and then one just for announcements or community matters. However a project organizes its mailing list(s), you typically will find the information listed in the CONTRIBUTING or README file.

Mailing lists are a great channel for long-form discussion, particularly among the members of a distributed community. Not only does a mailing list encourage more thorough answers, but by slowing down the conversation, mailing lists help to level the playing field for all participants. The asynchronous nature of mailing lists gives participants the freedom to take their time to craft their interactions. People can read and respond to discussions on their own schedule, without the always-online pressure that sometimes comes with a channel like real-time chat (discussed later). Mailing lists are especially useful when a community is globally distributed or otherwise includes people whose primary spoken or written language is not the same as the primary language of the project. The typically slower pace of a mailing list puts these people—who need more time to translate their ideas—on a similar footing to those who fluently speak the primary language of the project and community.

A project mailing list also is a remarkable historical resource for all community members and users of the project. While the feature can be disabled, nearly all mailing lists are archived by default, and those archives usually are publicly available and searchable. If you ever wonder, “Why does the project do things this way?” you usually can find the answer in the mailing list archives.

As I mentioned earlier, some projects have multiple mailing lists. This might seem like overkill, but what it does is allow people to get only the information they need rather than the firehose of all emails related to a project. These lists usually share a common name but have suffixes to help tell them apart and denote what sort of content that mailing list contains. Some common suffixes are -dev for lists dedicated to discussion about the technical development of the project, -user for questions and discussions about and by end users of the project, and -announce as a low-traffic list containing important announcements about things like new releases, conference information, security warnings, and similar things, but no discussions at all. Check the project’s documentation to see what mailing lists it offers and sign up only for those that are relevant to you. You can certainly sign up for all of them, but you may find you’re receiving a lot more email than you want or can handle.
Writing a Good Email

Over the decades, a lot of (mostly unspoken) practices and etiquette have sprung up around FOSS mailing lists. With mailing lists being such an important part of the communication strategy for most free and open source software projects, being able to write an email that adheres to these practices is a skill that will help you communicate while also avoid annoying people by transgressing email etiquette. Here are some tips to follow when writing a new message to the listserv (starting a thread):
Limit your message to a single topic and stick to it throughout the conversation.

Use a good subject line. As they say in journalism: don’t bury the lede. The subject should mention the topic you wish to discuss. Be brief and descriptive. If your question is about a specific issue, include the issue number in the subject line.

Start the message with your question, proposal, or thesis and then (if necessary), spend the rest of the message supporting it.

Keep your message text-only with minimal formatting.

If you require additional resources for your message, save these resources elsewhere and then link to them rather than cut and paste the content into the body of the email. These resources can include images or screenshots, source code, error messages, stacktraces, among other lengthy or space-consuming things.

While you can link to these resources inline where they’re mentioned in the body of your message, it’s usually preferred the links be referenced as footnotes in your message to help maintain the flow of the body of the text.

Do not include attachments in your message. Many mailing list software packages have a maximum message size setting, and attachments will cause your message to violate that setting and therefore, not be delivered. Instead, link to the resource as described above.

Here’s an example of a good mailing list message:
	​ 	FROM:
	​ 	TO:
	​ 	SUBJECT: page.lastupdate.datetime returns the wrong thing?
	​ 	We're updating the theme for the website[0] and thought
	​ 	it would be helpful for our visitors if each page showed
	​ 	when it was last updated. I checked the documentation and
	​ 	there doesn't seem to be an API method for getting this
	​ 	information?
	​ 	Then I dug into the source code for the page module[1]
	​ 	and found that there's an undocumented method named
	​ 	page.lastupdate.datetime.
	​ 	When I called that method I got back a POSIX epoch
	​ 	instead of a UTC timestamp like every other .datetime
	​ 	method in the API. I dropped an example into pastebin.[2]
	​ 	Should it be doing that? It's not documented, so it's
	​ 	a little hard to tell.
	​ 	--V
	​ 	[0]
	​ 	[1]
	​ 	page/
	​ 	[2]

Replying to a Mailing List Message

You would think that replying to a mailing list message is a relatively simple matter, but you’d be wrong. Many FOSS communities have strongly held opinions about what does and does not constitute a correctly formatted reply on a mailing list. It’s very easy to transgress these rules, and it’s very rare that they are ever written down. What follows are some of the most common rules for listserv replies, but as with everything with FOSS projects, you should do a little research before diving in. Have a look at the project’s mailing list archives to see how most people typically reply and then use that as a rule of thumb for how