Why you should contribute to Open Source

Seeing as open source software is made accessible and free to all, there are many rewards attached to developing and contributing to the same. Developers stand to gain a lot from the exercise, mainly when they contribute often. Here is a breakdown of some benefits of contributing to open source. 

Example: quordle game – quordle.today

Improving your skills

Open source projects come with a lot of demands, so many skills and applications are required to accomplish the tasks. This characteristic accords you as a contributor the opportunity to practice and build on skills you already have, and to acquire new skills as well.

Contributing to open source will allow you to practice in many fields that include (but are not limited to) graphic design, coding, writing, user interface design, organizing, and many others. 

To improve software that you and others use often

Most open source contributors almost always use software before they make a contribution to it. By using it, you are able to identify various bugs and flaws, making it easy for you to make contributions aimed at fixing the bugs. In so doing, you get the software to work better, making work easier for you and for numerous other users who are going to use it with and after you once it is fixed. 

In addition, you save others a lot of time and resources, especially those with limited skills and the ability to identify and fix bugs in software. 

To teach and learn from others

When you are working on an open source project which involves other parties, you are bound to encounter challenges and solve them. For this reason, you will be in a position to teach other people how to go through similar challenges. When you make inquiries, you get help from those in your community. This accords you the opportunity to learn new skills and techniques from them, and to also teach them how you go about your contributions.

This symbiotic relationship allows growth among many people at the same time as opposed to when one works by themselves. 

To build a network of like-minded individuals

One of the benefits of contributing to open source is that you get to build a network of people who have similar interests. You may, in the long run, end up with a community of colleagues-turned-friends that you can depend on for many things throughout your life. 

To learn how to deal with people of different personalities

When working with various teams, you are bound to interact with them in one way or another. What this means is that you acquire the ability to deal with different people and various circumstances. You will acquire such skills as leadership, conflict resolution, crisis management, delegation, work prioritization, organization, and others. 

To build a personal portfolio as well as a reputation

Working on open source projects accords you the opportunity to build a portfolio that proves the skills and abilities you have. You can use the said work samples as demonstrations to potential clients where skill is needed. In addition, you will be able to build on your reputation particularly because you can take credit for contributions made to certain software. 

It is a gratifying endeavor

As humans, we have the tendency to gain satisfaction and a sense of accomplishment when we complete tasks efficiently. Contribution to open source also provides the same opportunity as it gives you a sense of empowerment once you fix a bug or develop software to work better and more efficiently. The simple knowledge that you have made software more reliable and easier to use will give you a sense of accomplishment and gratification. 

Contributing to Open Source – What it entails

As a new contributor to open source software, you can find the process a bit difficult, and even unnerving. A step as simple as identifying a suitable project can be confusing, and a lot of the time, you may feel intimidated, question your skills, and even be afraid of making mistakes.

There are, thankfully, many ways to contribute to a project where multiple skills and levels of experience are required. Here is how to identify a suitable project and how to thrive in the same with little skill. 

Go beyond coding

One of the biggest misconceptions that many people have is that open source is all about coding. The truth is that there are many other skills and contributions that are just as relevant as coding. In most instances, contributors pay little attention to other areas such as writing, so it would do you a whole lot of good to make a pitch that does not include coding. Here are a few areas that may prove lucrative for you. 

Work as a designer

As a designer working on an open source project, you can;

• Redesign and restructure the layout of a project to improve its usability 
• Create and implement a style guide that will give the project a compatible visual design
• Improve and reorganize the project’s menus and navigation from feedback obtained from a comprehensive user research 
• Create art for merchandise like mugs, water bottles, T-shirts, and even the logo

Make contributions as a writer

As a writer, you can implement certain tasks such as;

• Creating or improving the project’s documentation
• Writing tutorials detailing certain aspects of the project
• Writing up translations for the project’s documentation
• Writing highlights from the project’s mailing list or creating a newsletter for the project
• Creating a folder containing samples and demonstrations on how the project works and how users can navigate it

Plan events for the project

If your strength lies in planning events, you can contribute to a project by;

• Organizing meetups or workshops pertaining to the project
• Come up with and submit proposals for conferences, and speakers and help community members identify suitable conferences around them
• Organize conferences for the project if they hold any

Work as a coder

If coding is your forte, you can;

• Improve the tooling and testing of the project
• Identify an open bug or issue to correct
• You can create or write a new feature for the project
• You can work on the project’s setup system for better user-friendliness

Help other people code

If, as a coder, you like to go the extra mile, you can;

• create tutorials and demonstrations on how a project can be used 
• Review the code on other contributor’s submissions
• Teach other contributors and offer mentorship to interested parties

Work as an organizer

As an organizer, you can accomplish some of the following tasks;

• Identify old issues and close them as you go through new open ones 
• Create links for duplicate issues and create new issue labels to keep everything organized
• Ask questions and make contributions to new issues that are relevant to a particular project

Offer help to other contributors and users of the project

When working on a certain project, you can help its users by;

• Giving information and answering questions about the project on various online platforms such as Quora and Reddit
• Act as a moderator for conversation channels and discussion boards pertaining to the project
• Answer people’s questions regarding open issues

Utilize your skills on non-software projects

While most open source projects almost always involve working on software-based tasks, there are other functions on which you can work that do not involve the same. You can contribute to a project by working on such items as stationery (books, lists), creating lists, and curating creativity programs for users and other contributors as well. 

These tasks can also be performed by software developers (especially beginners) looking to get into open source projects in the long run. Such tasks will provide an opportunity for you to develop your skill and confidence, and they will also help to build on your experience level and portfolio.

Learn the ins and outs of new potential projects

Making a contribution to a project by fixing a bug, no matter how small, can prove an intimidating task. One of the most important aspects and considerations that one should make is what the software at hand is all about, and whether or not a certain aspect needs fixing. 

Before you start to make contributions, it is important to know everything about the said software, right from how it works, its developers, how it is used, and so forth. With this knowledge, you will be in a position to make solid contributions that make an impact and that can also be noticed. 

What are open source projects comprised of?

Every open source project comes with its own community, and every community has its own unique footprint. This is why it is important for contributors to work on various projects in the long run. Different projects have different contributors, lexicons, work systems, communication styles, and so forth. Working on different projects accords you the opportunity to learn the different ways various projects are handled and run. 

Regardless, almost all projects present a similar organizational structure with each player assuming a different role than the other. A typical open source project will have the people outlined below;

• Project Owner; 

This is the person who claims ownership of the depository or entire organization. Note that they are not always the author of the project. 

• Project Author

This refers to the individual or organization that came up with the project.

• Contributors

These are all persons who have made a contribution to the project in one way or another. 

• Maintainers

These are the persons charged with driving the project’s vision as well as overseeing the organizational aspects of the whole project. In some instances, the maintainers are also the owners or authors of the project. 

• Users/ Community members

The project’s community is largely comprised of persons who use the project. They also offer feedback regarding the project as well as suggest the general direction in which the said project should head.

The people outlined above largely comprise small and medium-sized projects. Larger ones may include more players tasked with various other responsibilities. When going through a large project’s website, you may find such players as organizers, event planners, triage teams, community moderators, and others. 

Apart from the listed personnel, a project also comes with documentation. You will find these files listed in the top part of the depository. Here are the documents you can expect to see on a project;

• License

Every open source project is required to have an open source license. This means that any project without this license is not an open-source project. 

• README

This is an instruction manual designed to welcome community members to the project. It also details why the project is useful and how to navigate and use it. 

• Contributing

Unlike Readme documents which detail why and how to use certain software, the Contributing document file is made to help people contribute to the project. It explains in detail why certain contributions are necessary and how the contribution process works. Note that not all open source projects will have a Contributing file, but the presence of one is an encouragement to would-be contributors to study it closely and add value where they can. 

• Code of Conduct

As the name suggests, the Code of Conduct details how all members should behave and associate. It seeks to maintain a healthy environment for all stakeholders that is conducive for everyone involved. The presence of a CODE OF CONDUCT indicates that the project is a friendly one that welcomes contributors. 

• Others

Bigger projects sometimes come with other forms of documentation, some of which may include governance policies, walkthroughs, tutorials, and other similar works. 

Apart from the documentation detailed above, open source projects also come with certain tools which aid in the organization of discussion. A walk through its archives will give you a clear insight into how a project’s community thinks and operates. Here are a couple of common tools;

• Pull requests – This is where people review and discuss changes in progress

• Issue Tracker – This is where community members discuss issues pertaining to the project

• Synchronous chat channel – Some platforms may take advantage of synchronous chat channels to discuss collaborations, have quick exchanges, or for casual conversation. 

• Mailing lists or discussion forums – This platform offers a channel for conversational topics such as “How do I..” and so forth. 

identifying a suitable project to contribute to

This is easily the most difficult and possibly most important part of contributing to open source. The good thing is that there is always an abundance of projects that need and welcome open source contributions from people of different skills and experience. 

The best way to identify a project on which to work is to look closely at the projects you already use, that you are looking to use in the future, or that are used in abundance across the globe. They make excellent choices because you are bound to come back to them in your day to day activities even in the future. 

As you interact with the projects and different software, you may identify flaws or come up with ideas that could make the project work or run better. These would make excellent points at which to start. If a certain contribution seems too complex for your skill level, start with the simplest and work your way up. 

Some of the most common places to start are README documents. You can begin by scanning it and seeing whether or not there are areas of the same that need fixing or improvement. It could be something as simple as a typo – go on and start there. 

It has been statistically proven that up to 28% of open source contributions stem from fixing typos, documentation, writing translations, and reformatting. 

Below are a few links and resources that can help you identify and contribute to many projects;

• GitHub Explore

• First Contributors

• Contributor Ninja

• Open Source Friday

• 24 Pull Requests

• CodeTriage

• Up For Grabs

• First Timers Only

• First Contributors

• SourceSort

Picking a project – A step-by-step guide

Once you have identified a project to which you can make your contributions, it is imperative that you do a scan that lets you know whether or not the project is suitable for accepting any contributions made. You do not want to have worked on a project only to not get a response in the end. 

Here are a few aspects to look into to tell whether or not a project is suitable for new contributions. 

The Project meets the definition of an open source

• Does the identified project have an open source license? There should be a file labeled LICENSE in the root of the depository

The Project actively accepts contributions 

• When was the most recent commit?
• How many contributions does the project have?
• How often do people commit?

Next, look into the project’s issues

• Are issues responded to quickly by maintainers when they are raised by contributors?
• Can you identify active discussion on said issues?
• Are the said issues recent?
• Are the raised issues getting closed?

Look into the pulled requests

• How many open pull requests are available?
• Do maintainers respond promptly to pull requests?
• Are there active discussions on open pull requests?
• Are pull requests recent?
• How recently were pull requests merged?

The project is welcoming

A welcoming project will be open and friendly to new contributors

• Do maintainers give helpful responses to issues raised?
• Are people friendly in chats, discussion forums, and issue discussions?
• Do pull requests get reviewed?
• Do maintainers thank contributors?

How to submit your contribution

Once you have identified and worked on a project, here is how you should go about submitting a contribution.

Start by communicating effectively

As a contributor, one of the most important things to do is to successfully communicate and work with others. Before engaging a pull request, or asking a question;

Explain what you are doing

This will help the people with whom you are working to understand you better. If you want to suggest a new idea, for instance, let them know what it is and why you suppose it could be helpful to the project. 

Do extensive research

In case you need to ask a question or seek help, make sure you have exhausted all the information on the project’s documentation, README, pull requests, issues, and even the internet for an answer. Making effort will go a long way. 

Keep your requests direct and short

If you need to make a request, make it very short and concise. Remember that support is handling many people at a time, and you need to make their work easy. 

Communicate publicly

Make sure all questions, suggestions, and requests are made public unless you want to share sensitive or private information. Keeping communication public will help others with similar issues. 

Be patient when waiting for responses

Remember that issues and questions may take a bit of time, and some maintainers may need time to familiarize themselves with the contribution you are making. Try extending them some grace and wait patiently for responses.

Respect all community decisions

Each project has its own priorities and visions, and they may not always align with yours. If your contribution is not accepted or acknowledged, accept respectfully. 

Keep it sophisticated

When you are making contributions, remember that you are working with people from various countries, cultures, languages, and so forth. Keep your interactions respectful at all times. 

Gathering context

Before moving to make contributions, do research to make sure that your idea has not been replicated elsewhere. Go through the project’s README, open and closed issues, and so forth. If the idea has not been implemented, you are good to go.

Before opening a pull request or issue, make sure that you go through the contributing documents to see whether you need to use a specific template or use a test. To make solid contributions, open an issue to ask maintainers before starting on it.

Opening an issue

Here is when to open an issue;

• To report an error, you are unable to solve
• To discuss high-level ideas or contributions
• To propose a new idea

Tips on how to communicate issues

In case the issue was opened a while ago, it is likely that someone is working on it. Seek clarification before proceeding.

If an issue is already open comment and let everyone know you are handling it to avoid duplication.

If you opened an issue but solved it on your own, let everyone know and close the issue.

Opening a pull request

You can open a pull request in certain situations;

• To submit insignificant fixes
• When starting work on a contribution that has already been discussed or worked on in an issue

A pull request does not have to represent work that is already complete. You can mark it as work in progress (WIP) or add more commits later on. If you are working on GitHub, here is how to submit your pull request;

• Fork the depository and clone it locally. Connect to the local upstream depository by adding it as a remote. Keep pulling changes from upstream to stay up to date so as to avoid merge conflicts.

• Create a branch for your credits. 

• Reference relevant issues or supporting documents in your PR.

• Include before and after screenshots in case your changes have different HTML/CSS. Drag and drop the screenshots into the body of the PR.

• Maintain the project’s style as best as you can. This makes it easier for maintainers to merge similar requests, and for others to understand and maintain PRs in the future. 

What to expect when you submit a contribution

Here are a few likely scenarios that may present when you submit a contribution;

Someone requests you make changes to your contribution

If this happens, be responsive and make the changes. If you are not in a position to, let the maintainer know that you will not manage it, and they may let someone else do it.

You do not get a response

If you do not get a response in a week, you can respond on the same thread and ask for a review. In case this is not responded to, it is likely that you will not get a response at all. Try and find another project or another way to contribute. 

Your contribution does not get accepted

There is no guarantee that your contribution will be accepted. In case you are unsure as to whether it has been accepted, ask the maintainer for clarification or feedback. Make sure to keep it respectful. 

Your contribution gets accepted

Congratulations, you have made an open source contribution successfully. 

Final thoughts

Beginner or pro, it is always a gratifying feeling to make an open source contribution successfully. Be sure to look for open source projects to contribute to so as to build your portfolio. Finally, make sure to thank the maintainers who take the time to help you!

The post How To Contribute to Open Source appeared first on CONTRIBUTING.md.

So, what is open source, and why should you open it? 

Opening an open source takes courage and determination. If you have decided to contribute to the world in this way, we applaud you. Now, let’s look at how you can open an open source successfully.

What does the term “open source” mean?

An open source project is a licensed project available for modification, study, distribution, and use by any person who comes across it for any reason. These projects require licensing by an open source license.

An open source is the complete opposite of a closed source project where the latter does not allow users to control their computing. An open source project mandates you to collaborate and lets people adopt your idea for personal use. Due to the transparency of the projects, people can offer improvements and contributions quickly.

Open source projects operate like free software. You might come across free and open source software (FOSS). You might also come across free, libre, and open software (FLOS). The term free in this perspective has nothing to do with pricing, but with how it’s used.

 For instance, a business with open source software can get the services of an independent person to customize it and make modifications. However, a closed source gives you zero mandate on the modification of the product.

Why do people open source their work?

Many reasons drive people to open source their work. Some of these reasons include collaborations from all over the world, transparency that comes with opening an open source project, and letting people adopt your idea for their use. Let’s look at these reasons in detail.

Transparency: Any person is allowed to check for errors and inconsistencies. These features matter most in the governments of Bulgaria and the United States. Transparency is also important in regulated industries like banking and healthcare and security software like Let’s Encrypt.

Partnership: An open source project brings collaborators from all walks of life. Exercism is a project with more than 350 contributors worldwide.

Adoption and remixing: Any person is free to use an open source for any reason. People can use your project to come up with new ideas. For example, WordPress started as a fork of a project called B2.

Github has all the answers you need to explore the world of open source. You will be surprised to find other possible open source project ideas like data sets.

Are open source projects free of charge?

While one source projects allow users free access, free of charge does not apply to the definition of open source. What does this mean? It means that the owner of the project can assimilate ways to charge for an open source project indirectly including dual licensing and limited features. This way, you will still comply with the idea of open source.

The term free is only applicable because all users are allowed to modify, use, duplicate, or share for whatever reason. In simple terms, a user can contribute and do a multitude of things, but there will be features that will require making payments to access. If there were charges on a project, anyone would be legally able to duplicate and use the free version. 

Section two: Should I start my open-source project?

Yes, why not? No matter how it turns out, you will have a good chance of learning how the concept of open source works. The first open source is always nerve-wrenching with thoughts of what people will think or if they will see your project at all. You might be feeling intimidated by the thought of sharing your ideas with the world, but it’s the only way to practice with or without an audience. If you have been harboring such thoughts, this happens to all people when they are starting. 

Setting your objectives

If you are still in doubt, take a moment and think about your goals. They will help you to figure out what to dedicate your energy to and whether you need help. If your only reason to start an open source project is to show off your work, you will not need contributors as your only interest is to show the world what you’ve got. This becomes so much easier when you ask yourself what your motive is in starting an open source project. Whether it is just for show or any other goal, you need to communicate this in your README file.

As your project expands, you will find that you will be needed to resolve issues, appraise codes, and evangelize your project. You will become a maintainer, and the amount of time you spend on non-coding tasks will depend on the scope and size of your project. If you are in a company that plans to open source its project, confirm that you have adequate internal assets to succeed.   If you can’t address them yourself, you can get someone to help you.

You need to pinpoint the maintainer after launching your project and the tasks to allocate to the community. 

Contributing to other projects

The best way to launch a successful open source project is to contribute to an existing one. This way, you will get a full understanding of how open-source projects work. Begin by contributing to a familiar project that you love. Contributions do not have to be complex, as you can begin by simply fixing typos and updating documentation. If you have no idea how to contribute to projects, check out available guides on the same.

Debut your open source project

The debut of an open source project does not have an allocated timeline or an opening season. You can dive right in after years of being closed source or a new idea.

There are the constituents that will help a maintainer communicate prospects, safeguard the legal rights of everyone, and manage contributions. If you have the guts to receive feedback, reviews, and comments about your work, you are ready to open source your project. Every open source project, no matter the stage you opt to open source requires the following:

• README
• Contributing guidelines
• Open source license
• Code of conduct

There is little doubt of having a negative experience with this. If you are using GitHub, you will need to put these files on the root file with the correct names for GitHub to identify them and surface them for readers.

Choose your License

This is a basic requirement for any open source project. This license warrants that any alterations, use, or duplication to your project can be done without repercussions and keeps off sticky legal circumstances. No one wants to be in any legal battles when all you need to do is duplicate an existing license into your repository and be on the safe side. You can check out the most popular open source licenses, such as MIT and Apache 2.0. Github offers you a chance to select a license of your choice after the début of your project.

Write your README

While some people skip writing a README as they feel the project is incomplete or does not need contributions, these are the same reasons your project needs one.

There is more to READMEs than mere descriptions of the purpose of your project. These documents tell users what they can do with your project. You should strive to answer the following questions in your README:

• What your project does
• Why your project exists 
• How to get started
• Where to get help?

Other questions you can tackle on your README are how you handle contributions, what goals are set for the project, and information on licenses and contributions.

The moment you include a README file on the root directory on GitHub, you will see them surface on your repository page.

Write your contributing rules

The CONTRIBUTING file on your project offers information on how to use your project and how to contribute. Some of the information you can include is:

• Using the pull request template to report a bug
• How to propose new features
• How to run tests and set up your background

That out of the way, you need to use this file to communicate your anticipations, such as:

• The kind of contributions you are seeking
• The vision or roadmap of your project
• How contributors can reach or not reach you

You can link your CONTRIBUTING file from your README to increase exposure. When using GitHub, ensure that you place your CONTRIBUTING file to the project’s repository file for an automatic link by GitHub when a contributor opens a pull request or creates an issue.

There are some things you can do to help newcomers feel welcome, like using a warm, friendly tone and making suggestions on how they can contribute e.g. in the documentation and making a website. These simple gestures can make new users feel welcome and valued.

Do not complicate the CONTRIBUTING file in the early stages of your project. Strive to keep things like how to report a bug or any technical requirements like tests simple. As you progress, you can add an FAQ section to your file to keep people from asking the same question over and over.

Create a code of conduct

Ground rules are important to keep the behavior of your community in check. The code of conduct outlines who these rules ply to, when they apply, and what happens when they are not followed. This is vital if you intend to launch an open source for a company or community. Like the open source software, there are available standards for these codes of conduct, and you do not need to draft your own. A good example is the Contributor Covenant code of conduct, which has over 400,000 open source users.

This is the tool that helps you regulate the behavior of the community and keep it healthy while reducing stress for yourself. When someone breaks the code of conduct, you can refer them to the file that contains these guidelines. You just need to paste the text directly to your CODE OF CONDUCT file in your repository and keep it in the root directory for an easy link from your README.

Title and brand your project

Branding is about how you convey your message to your potential users and the impression they get from your messages. It is not all about the fanciness of logos and catchy names.

Choice of names

This might seem like a walk in the park due to the ideas that are flowing in your head, but it is more complicated than that. Let the name match the idea of the project, and it’s easy to remember. A good example is Thin: A fast and simple ruby web server. Nobody is likely to forget a name like Thin. 

The post Starting an Open Source Project appeared first on CONTRIBUTING.md.

Spreading awareness of the project.

When launching an open source project, it’s not mandatory to promote it. It is completely fine to work on open source projects that aren’t as popular. However, spreading the word about your project is useful if you want other people to find and use it.

Find out how to phrase your message.

Before you start spreading awareness or promoting the project, you need to be in a position to explain to others how the project works and what they can gain from it. Ensure you can explain what distinguishes your project from other projects and what inspired you to create it. Being able to explain this will assist you in effectively and easily communicating the importance of your project. 

If you solve a problem for your users, they’ll eventually become contributors to your project. So, as you figure out your message, try your best to have the user’s point of view.  There are various materials online that can assist you in figuring out how to communicate your project. 

Make your project discoverable to people.

Directing people to your project is a crucial step and you can do this by pointing them to a single namespace. This will make people easily discover the project and remember it. Ensure you have a clear handle to promote your work on platforms like Twitter, GitHub or IRC channel as this is a simple way to direct potential users to your project. Having handles in the mentioned platforms will provide a place for your project’s users to convene. 

However, if it’s not your priority to set up outlets for the project, you can also promote your Twitter or GitHub handles so that people will know how to contact you and follow the project. Also, if for instance, you speak at meetups or events, be sure to always include all your contact information in your bio and the presentation slides.

Another important thing to consider is creating a website for the project you wish to find users for. Having a website for your project will make the project appear friendlier and also, it’ll be easier for potential users to navigate. Pairing the website with say, clear documentation and tutorials will help even further. To a user, a website indicates that the project is active thus making them feel comfortable using it. Websites like Yeoman, Middleman and Vagrant are great websites as they are comprehensive.   

Last but not least, it helps to provide examples so that people know how your project is used. After figuring out a message for your project and setting up ways for people to easily find you, the next step is to talk to your audience.

Find your project’s audience online.

Online platforms provide channels that will assist you in sharing and spreading the word quickly, reaching a wider audience. It is smart to take advantage of online communities and platforms that are already in existence, to get to your audience. For instance, if you have a software project, your audience is most likely on platforms like Stack Overflow, Quora, Reddit or Hacker News. Always find platforms where you think people will be the most excited about your project and benefit from it. 

Other relevant ways to share your project include;

Firstly, find people who have a problem that your project can solve. Dig through relevant forums to find people who are your potential target audience, answer the questions they have and tactfully, when appropriate, suggest your project as a solution.

Secondly, it helps to know communities that are relevant to your project. You don’t always have to be promoting your project. Sometimes, take time to know your communities and this may naturally give rise to opportunities for you to talk about your project. 

Lastly, always ask for feedback when you introduce your work to an audience with potential users. Instead of being fixated on promoting your work, try to listen and respond to the feedback of others and also ask for their opinions. This way, you may discover ways of improving your project. 

Bottom line is, to be more intentional about helping others instead of focusing on what you can gain. Since very many people are promoting their projects online, be unique and give people context of who you are and always be patient as not all projects take off when they launch. If one way doesn’t work, look for other ways and always give your users’ needs priority and remember project launching and promoting takes time and dedication.

Find your project’s audience offline.

Offline, you can find your project’s audience in meetups, events or conferences. When feeling overly nervous, remember that the audience is present because they actually value and want to know more about your project. When preparing for the talk, prioritize what your audience will find helpful and interesting. During the presentation use friendly and kind language and remember to breathe, smile and have fun.  

Conferences are particularly a great way of helping you reach a wider audience, sometimes even from across the world however, they need a lot of preparation and great presentation. So, you’ll have to practice a lot. Always research the conference to tailor your presentation to fit the attendees and before the conference, look at the other speakers to predict what kind of audience to expect.

Build a good name for yourself and your project.

Building a good reputation for your project and more importantly for yourself will go a long way to attracting users to your project. Acts like assisting newcomers, making meaningful contributions to the projects of others and sharing resources, help build a positive reputation. Also, being an active or contributing member of the open source community will enable others to be aware of you and your project.

In addition to that, developing good relationships with other projects may even lead to official partnerships. Remember that it is never too late or too early to start building a good and positive reputation for yourself and your project. The great and easiest way to build a good and positive reputation is to always look for ways to help others and give your users’ needs priority. Building a good reputation among your audience is a never-ending process, since gaining the respect and trust of other people takes time and effort. 

Maintain the effort you’re putting in and be patient

It’ll most probably take some time before users start to notice and use your project and that is completely fine. Some of the most famous projects known today took years to get to the high activity levels they have. The best way to maintain a successful project and have loyal users is to build genuine relationships instead of focusing on the popularity of your project.      

The post Finding users for your project? appeared first on CONTRIBUTING.md.

How to ensure that you set up a successful project

Any successful project requires a welcoming community to maintain its reputation and success. If your project is starting to pick up, it is best to reward the early contributor with an unforgettable experience. This way, they will keep coming back.

Making people feel wanted in your project

According to a survey conducted by Github in 2017, the greatest problem for open source users was confusing and incomplete documentation. When your documentation is in order, you will invite useful contributions and interactions to your project.

In every stage of a contributor’s experience, you need to reduce the friction. According to Mike McQuaid, one should think about the community’s project in what he calls the contributor funnel. The top of the funnel is made up of potential users, while the bottom of the funnel is made up of active users. 

While community building, one must consider how to get those at the top of the funnel to the bottom. When returning users get a good experience, they keep coming back. The first step is to put your documentation in order.

To make it easy for beginners, label the issues they can tackle with ease. Github surfaces these issues all over the platform and results in meaningful contributions. This way, you will reduce the friction of users as they try to solve issues that are beyond their level.

Make a user-friendly project. The project needs a friendly README segment that tells all about the project.  Clear codes will give the users a clear head start.

Let your users know how to contribute to your project in your contributing file and keep everything up to date. During these interactions, a few people will pull requests or open an issue, and this is the opportunity to pull them to the bottom of the panel.

Most open source contributors are casual contributors, meaning they only do so occasionally. This does not mean that they are not important. On the contrary, you should make it easy for them to make contributions whenever they can.

When you get a new user on your project, the first step is always to show appreciation to them for their interest. A single negative experience is enough to make a user never return to your project.

Prioritize responding to users. When you postpone responses for weeks, chances are that the users will have long forgotten about your project when you respond. When you encourage your contributors, you are simply investing in your project. When contributors are excited to carry on with the work, the pressure to do everything alone will be removed.

Be open about all the contributions that will come your way. There are several ways people can contribute to a project, and it’s good to let people do what they can.

As much as you are open, there are contributions that you will disagree with. In such a case, thank the contributor and explain to them why their idea does not fit the scope of your project, and link to relevant documents.

Keep your documentation up to date

Open source projects thrive when everything is in the open. It is natural to want everything private with a new project, but imagine wanting to contribute to a project and not knowing what you are contributing to and why. This is why documenting everything and making it public is vital.

You need to be transparent about the roadmap of your project, and the contributions you expect to get. If you notice a repeat of the same problem with multiple users, you need to update your README and include answers to these problems.

If the workload is substantial, you will need to have a pull request and mark it as a work in progress (WIP). The contributors will feel included from the early stages of the project.

Writing things down helps contributors participate at every step of the way. You might get an idea of something you didn’t even know you needed. Writing down is not just restricted to technical documentation, but anything you feel should be publicized.

Don’t leave anything out, including any meetings held. Document all the takeaways and relevant issues and publish your notes. You will be pleasantly surprised by the feedback from this kind of transparency. The publishing should be inclusive of all the work that you do. 

Prioritize being responsive

A study conducted by Mozilla revealed that codes that responded within 48 hours had positive returns and encouraged return contributions. We can’t emphasize this one enough. If you put your project in public, you will receive all kinds of feedback. People will need help to start or have questions on different things. If someone files an issue, you have to respond as soon as possible. When you respond swiftly, you will create a dialogue, and people will get enthusiastic about your project. 

 When you are unable to respond immediately, you should acknowledge receipt of the issue to increase engagement. Conversations about your project can be carried out on other platforms such as Twitter, Reddit, or Stack Overflow. You can set notifications whenever someone mentions your project on these platforms.

Create a place for the community to meet

There are two main reasons you need to have a place for the community to congregate. The project is about them, and people with similar ideas would appreciate a common place to discuss their ideas. Those joining the project can catch up in the archives. 

Secondly, this can be a stress reliever for you. When there is no public forum, people are likely to contact you directly with questions. This might seem easy at first, but it could get overwhelming with time if your project becomes popular. Don’t fall for the temptation to engage people privately, but direct them to a public forum.

The easiest way to respond to issues is to direct people to raise issues in a public forum instead of direct messages to your email. You can opt to create a Twitter account or IRC channel for people to discuss your project. You could also set aside some office hours to help the community.

Note that the best way to keep your public forums conducive for all is to have a method of taming misconduct and violations. You can have a mechanism where people can report abuse, misconduct, and violations privately. Create a dedicated email for this if you do not wish to use your email.

Expand your community

Growing your community numbers can be good or bad, depending on your approach. There are mechanisms you can use to become a force of construction.

Don’t accept bad behavior

When a project becomes public, it is bound to attract the wrong crowd. They can deviate from the issues with unnecessary topics, become bullies, or quibble over non-issues. As much as you are looking for contributors, you do not need these, and you must adopt a zero-tolerance for this behavior. If you turn a blind eye, other members of your community will be left uncomfortable and can leave.

Irrelevant debates over trivial issues are a distraction to the community and you from the real issue at hand. These can upset new members and make them unwilling to participate. When you notice any negativity, do not hesitate to call it out publicly.

 Do not be rude, but apply a firm tone. If this doesn’t stop the behavior, you may need to ask the involved parties to leave. You can have a clearly outlined code of conduct as a path to constructive communication.

Meet contributors are their level

Your contributing file should have a dedicated place for how to get started for new contributors. The need for proper documentation only increases with the growth of your community.  A special landing page for new members can work perfectly for this purpose.

This documentation comes in handy for casual contributors who go through them to get the drift of your project. The issue queue should have bugs labeled for new members, e.g. first timers only or good first issue. These bugs will make it easy for a newcomer and get them started as quickly as possible. Your documentation should make people feel welcome at all stages.

It is impossible to interact with all people who land on your project. Some contributions could have escaped your reach as a contributor might have felt intimidated or confused at the starting point. Apply kind words to keep people from leaving your project.

Let the community feel a sense of ownership of the project

When people feel a sense of ownership, they get attached to a project. This should not make you turn your vision over to people or accept unnecessary contributions. However, when you give people credit, they are bound to stick around. Some sharing ideas include;

Write a blog post or a thank you newsletter to all contributors if your community is sizeable. Good examples of these are Hoodie’s shootouts.

Don’t resolve easy bugs: Delegate these simple tasks to new members. You can also recruit new members or mentor someone willing to contribute. This is not an overtime investment and can seem unnatural at first, but it pays with time.

Start an AUTHORS or CONTRIBUTORS file for your project and list everyone who has made contributions.

Opt for commit access for your contributors. This way, they will be excited to polish their patches, and you might be lucky to find new maintainers for projects that you haven’t worked on for a while.

If you are using GitHub, shift your project from a private account to an organization account with one backup admin. This is much easier to work with external collaborators.

Most of the projects have a maximum of two maintainers who work single-handedly. When your project is big, this translates to a bigger community, which means ease in getting help. As much as you might not find someone to answer the call immediately, putting out a sign helps when done as soon as possible.

Conflict Resolution

When the project is relatively new, decision-making is always easy as you do whatever suits you. As your project expands, your decisions become important to other people. Even when your project has many users and only a few contributors, your decisions will have an impact. If you have done everything right from documentation of everything and cultivated a friendly community, your community will not struggle with finding solutions. However, you are still prone to issues that are not easily solved.

Let kindness be a priority

Tempers can rise when a community is grappling with a particular issue. When this happens, people can turn on each other or you. This is where your role as a maintainer comes in to avoid escalation. You must always strive to act as a moderator or facilitator and never fall into the temptation of jumping into the fight. You might not realize it, but other people are looking up to you, so set a good example. This applies even when your opinion on the topic at hand is strong. If someone goes out of the code of conduct, act immediately to keep things civil and productive. If you need to express your disappointment or disagreement, do so calmly without aggravating the matter.

Make your README a Constitution

Your README page should be much more than a mere set of rules. This is also a place to sell your goals, vision, and roadmap. When people are overly drawn to one feature and insist on debating it, it becomes inevitable to visit your README and edit it to accentuate your higher vision for the project. This helps to depersonalize the discussion and focus on the entire project for fruitful discussions.

Don’t place your focus on the destination and neglect the journey

Voting is inevitable and gives a tiebreaker, but one should emphasize seeking consensus rather than consensus. The consensus-seeking process involves sober and thorough discussions that offer the community a platform to air their views until they feel that they are adequately heard and the community moves forward when all major concerns are addressed.  Some projects will use a voting process for major decisions. While this will swiftly offer a solution, it might not address each concern and offer a listening ear. This can quickly turn political where people vote to return favors to others or feel obligated to vote a certain way due to pressure. Most silent followers in the community won’t vote, and new users who are unaware of any voting taking place. The consensus method does not aim for a perfect answer but offers a platform to listen and discuss.

Don’t let the conversation deviate from action

Learn to differentiate between productive and unproductive discussions to avoid time wastage. You are at liberty to shut a discussion down if it goes off-topic or people start to turn on each other. When you let it slide, you risk hurting the health of your community and discrediting the issue at hand. Shutting down sends a message that those discussions are prohibited, but if let to continue, future discussions will only get far from the real issues. Refocus the group by asking questions like ‘what step should we take next?’ If a solution has been reached, or the discussion is not heading toward any solutions, close it and explain your action. Only encourage discussions that are steered towards the solution.

Don’t intervene when it’s unnecessary

Always put context into consideration and look at who is involved in the discussion and how they represent the community. Look at the mood of the community in the discussion and consider the silent community and their feelings. If the issue does not touch the broader community, you cannot neglect the minority. If the issue is recurrent without any tangible solutions, point the people to a previous thread that addressed the matter and close the current thread.

Find a community tiebreaker

When communication is clear and a positive attitude intact, most issues are easily resolved. However, even productive topics can raise contentious issues that lack a definite way to proceed. This can be solved by individuals or groups that can break the tie. However, the tiebreakers should come as a last resort as divisive issues are vital for your community’s growth. A tiebreaker can be primarily the maintainer of the project or a small group of voters. You will have successfully identified a tiebreaker and a related process in the GOVERNANCE file way before you ever put it to use. Take hold of these opportunities and forge a collaborative process to get to a resolution at all times.

Community is everything for open source

The fuel to the endless hours spent on open source weekly is a healthy and thriving community. The majority of contributors point fingers as the reason for failure to work. This power can be tapped positively to help someone get an unforgettable open source experience.

The post Building Welcoming Communities for Open Source appeared first on CONTRIBUTING.md.

Who is a maintainer?

A maintainer codes and addresses issues in an open source project. When you become a maintainer for a popular open source project, you will notice that your coding decreases and attending to issues increases. Your interaction with users and contributors will increase significantly.

When the project is still young, you are more focused on your ideas and what you want to implement. Most, if not all the time, you make decisions on your own. As the project gains popularity, you find that your time is taken by interactions with users and contributors. Project maintenance is more than code with more unexpected tasks that are equally important. Below are a few ways to ease your maintenance job, from documentation to community leveraging.

Writing down your Processes

Documentation is the most vital task for any maintainer. 

When everything is out in the open, people find it easy to contribute. Documentation is not only vital for clarity of your thoughts but explains what you need or what you expect from users before they ask. When everything is well-documented, it becomes easier to turn down ideas outside your scope. 

Whatever you do, whether you opt to write full paragraphs or a brief bullet list is better than no writing at all. Always strive to keep your documentation updated and when you cannot do this, indicate outdated files so that contributors can be informed that they are welcome to give updates.

Document your project’s vision

In your README file, outline your project’s goals, or opt for a separate VISION file. Publicize all artifacts that can be useful for your project like the roadmap. A well-outlined vision keeps you focused and avoids scope creep from your contributors.

As a new maintainer, one person narrates how he regrets steering away from his vision in the early stages of his project when he got his first feature request. He appreciates that a clear vision has kept him focused and helped him prioritize important requests.

Document your expectations

When new users come on board, they have no idea about you or your project. Some assume you are an employee, especially if they use your project regularly and depend on it. This perception might have stemmed from the ample time you gave to your project before, but this does not always last when you have other things to attend to. While this is unavoidable, ensure that you let others know you won’t be available as much as you used to be. If you won’t be on the project on weekends, let the community know this.

While rules seem like you are policing others and killing all the fun, they are vital for your project’s success. They can be nerve-cracking, but when enforced fairly, they are empowering to maintainers. These rules will protect you from getting dragged to do things outside your scope.

If you’re a part-time maintainer or a volunteer, make sure, to be honest about it and tell everybody how much time you can dedicate. This is not a reflection of how much time is required for the project. Some of the rules worth documenting are:

The procedure of reviewing and accepting contributions (Indicate if tests are required or if there is an issue template).

Acceptable contributions (Indicate if you want partial help with your code).

Indicate the appropriate time to do a follow-up (You can say something like, ‘Expect a response from a maintainer in 7 days. If you haven’t heard anything by then, feel free to contact us).

Communicate about your availability on the project per week (You could say, ‘we spend 5 hours per week on this project.’

All communication should be made public

Whenever possible, keep everything public. When you have a private maintainers meeting, document the details of the meeting, even if it’s in notes form, and put them out in the public. This makes sure that new members are integrated into the project and become on par with everybody else.

When a user tries to have a private discussion about a feature request, politely direct them to a public channel like an issue tracker or mailing list. Write down all your interactions without fail

Saying no

The maintainer needs to constantly remind people about existing information even when everything is properly documented and in the open. When all rules are written down, you will depersonalize a situation when enforcing those rules

The choice of words when turning down a contribution is key. You can say ‘your contribution doesn’t match the criteria of this project instead of ‘I don’t like your contribution.’ The word no will come up in many situations as a maintainer. Situations like someone derailing a conversation, a contribution that doesn’t match the scope of your project, and doing unnecessary things will require a firm no.

Maintain a welcoming conversation

When a project is public, all manner of contributions will steam in including those outside your scope. The idea can be good with a poor implementation or it’s simply not in line with your vision. A firm no will be inevitable on your pull request queue and issue. Whatever the case, you must be tactful in handling such requests. If you adopt a mechanism of ignoring unfavorable requests or pretending not to see them, you will end up hurting the contributors and demotivating other contributors in your community. When you ignore contribution, you send negativity to the community.

The thought of saying no is terrifying, but it’s inevitable. This, by no means, shouldn’t make you guilty because a yes is forever, but a no is temporary. Never leave an unwanted contribution open to seem nice or to avoid hurting others. This will come back to haunt you when things start to feel intimidating and stressful.  Close contributions that you are sure you don’t need, immediately even if you have a backlog. You can adopt a triaging mechanism for your issues.

The first contribution is never easy for new users, and you need tact to handle this. Always thank people for their interest before turning them down.  If you need to turn down a contribution:

• Appreciate the contribution with a ‘thank you’.
• Explain why you have rejected it and offer some relevant suggestions. Keep it firm, but kind.
• When issues you don’t want to accept keep repeating, add them to your documentation to avoid repetition.
• After responding with 1 or 2 sentences, close the request.

When you reject the idea, this doesn’t mean that you reject the person, and therefore you do not feel to harbor any guilty feelings. You are not obliged to accept a contribution to please people. While maintaining kindness and being responsive, only accept ideas that are aligned to your project. When you practice saying no, it becomes easier with time.

Take a Hands-on approach

In your contributing guide, be precise on the reviewing and acceptance process. This way, you will save yourself from a high volume of unwanted contributions. If the low-quality contributions surpass the high-quality ones, you should put a measure in place for contributors before they get to the submitting stage.  Some of the measures you can put in place include:

Request contributors to fill out a PR checklist or template.

Opening an issue before submitting a PR.

Being proactive is the surest way to eliminate unwanted contributions. You’ll also be saving contributors from investing their time in something that will ultimately get rejected. Ultimately, your workload reduces and becomes manageable. 

At first, you might get criticized as people get upset for rejecting their ideas. If any person ignores the rules, close the issue immediately and direct them to your documentation. It might seem unkind, but it is the surest way to keep things focused. If the hostility escalates despite efforts to calm things, you should remove them from your community.

Promote mentorship

When a willing contributor always submits substandard contributions, it can get frustrating for them. If you encounter someone enthusiastic about the project but are constantly getting rejected, exercise patience. Keep explaining clearly why you have rejected each contribution and try to point them in the direction of easier tasks like something marked as a ‘good first issue’, and they can grow from there. You can mentor them from that point if you have some time to spare or find someone who can mentor them.

Engage your community

Your community can come in handy to offer you a helping hand. That’s why it’s there in the first place, so you don’t need to overburden yourself. If your community is not active and has many users, put the users to the task.

Delegate the workload

You might want a temporary break or to leave the project permanently, and you can ask someone to take over. You can identify enthusiastic people and give them commit access or simply hand it over to someone else completely.

Ask for help if you want people to pitch in. The best way to get help is to label simple tasks for beginners to tackle. GitHub works by distributing these issues all over the platform to increase their visibility. When you notice an enthusiastic and positive contributor, reward them by assigning more tasks and documenting how others can take up leadership roles in the project. Encourage the community to share ownership of the project to ease your workload.

 If someone is maintaining your project elsewhere, you can link the fork to your original project. It is a plus for people to want to keep your project alive.

A maintainer found that documenting his project’s vision helped his goals thrive long after he stepped away from the project.

Encourage forking among the community

When you let community members fork, they can exercise their creativity on their projects without interfering with your vision. As a project grows, it becomes inevitable for maintainers to take a conservative approach in their introduction of new codes. As much as you keep saying no, there are people with legitimate needs, and that is when you end up turning your project into a platform.

You might encounter a contributor whose opinion differs from your project. You should gently steer them towards starting their fork. Duplicating a project is never a bad thing in open source projects.

 When a user requires a solution you do not have the bandwidth to build, you can offer APIs and customization hooks to meet their needs. According to one maintainer, encouraging plugins for Cocoapods created some interesting ideas. 

Bring in the bots

As a maintainer, you must have sort help from fellow humans. Similarly, you can seek help from robots to accomplish some tasks.

Introduce tests and other checks to level up your code quality

Make a requirement that contributors should pass the test before making any submissions. That way, you will reduce low-quality submissions by a country mile.

When a contributor is subjected to a test, they gain confidence as they go, especially when they pass. This is the simplest way to automate your project without having to manually reject contributions. When you increase your responsiveness, you increase your community’s engagement. The surest way is to run automated tests on all incoming contributions, but ensure that they can easily be run locally. 

When using GitHub, you should put a status check requirement to ensure that no change merges happen without passing the tests. Ensure that you add how these tests work on your CONTRIBUTING file.

Utilize available tools to automate simple maintenance tasks

There are available tools for maintenance and automation. Working on a popular project is easy as other maintainers have walked the path before, experienced similar problems, and made solutions. GitHub offers templates and pulls requests for contributions like bug reports which can be used to streamline received communication.

Other readily available tools include:

Mention-bot that mentions prospective reviewers for pull requests.

Semantic-release for automatic releases

No-response automatically closes an issue if there are no further questions.

If you aren’t sure about the right tools for your project, you can borrow ideas from other projects, especially those in your specialty. Using familiar tools makes it easy for the contributors. For instance, look at what other Node module contribution process looks like.

For email notifications, you can set up an email filter to prioritize. If you desire to advance, you can opt for style guides and linters to standardize contributions for easy review and acceptance. However, be careful not to have complex standards as they can create a barrier to successful contributions. Ensure that rules are only to make the community’s life easier. 

Taking a break is okay

Burnout is unavoidable in open source work, especially for maintainers. You might find that the joy you once felt while working on your project has been drained. You could be feeling overwhelmed and stressed out by the mere thought of your project as issues keep piling up. The success of your project is proportional to your happiness, and therefore should be non-negotiable.

When this happens, it’s time for a break. Do not wait until you can barely function to take a vacation. Taking regular breaks is vital for your health and refreshment, and you will find that you enjoy your work more. One Python core developer by the name of Brett Cannon took a month off after 14 years of volunteer work. Sometimes, you might feel obliged to stay and keep working when you think that everybody depends on you.  Don’t do this. All you need to do is inform people when you aren’t available to avoid confusion from your sudden unresponsiveness. Breaks do not have to be about vacations. You can take weekends or working hours off from the open source, but communicate first to prevent people from bothering you.

You come first

As a maintainer, you will incorporate both personal and leadership skills at a level many will never experience. While it is not always comfortable, definite boundaries and only taking up what you can handle is the surest way to a happy, reproductive, and refreshed life.

When a project grows from its initial stage and becomes popular, the maintenance skills increase as well. This is not a bad thing as it is super rewarding, but you need to take care of your well-being before anything else. 

The post Best Practices for Maintainers of Open Source Projects appeared first on CONTRIBUTING.md.

1. Comprehending the right administration for your sprouting project

The complexity of contributions in a project increases as the project continues to grow.  Cooperation between the makers and the contributing takers becomes more difficult to control, as communication, and trust reduces due to heated disagreements.

Various governance models have been used in thriving open source projects and have been a success. They include:

• Self-governance approach

This model is common in small open source communities. It makes it easier for members to share their thoughts freely, communicate amicably and learn who they can trust. Incorporating strong norms that persist in fairness in teamwork and meeting face to face can help keep things orderly in the project using this model as it promotes harmony among the members.

• Privatizing open source government

This model aims to create a positive social benefit for all members included in the open source project. This is done by giving special benefits to makers, which are not accessible to takers. It aims to commercially benefit all participants while giving credit to the pioneers of the project. The model has worked for big companies like Mozilla, Mongo DB, and Redis which are successful brands. 

• Centralizing open source governance

This model is driven by the economies of scale, whereby other companies fund these projects till they capture a new market. The investors mainly aim at making them their monopolies and collecting the gains. Peter Thiel the investor of Facebook is living proof that this method works.

Understanding the right governance model to use among the above for the governance of your growing project is hence crucial.

2. Examples of the common duties utilized in open source projects?

Different projects have varying formal roles depending on the agreement of the members. The commonly used roles include:

• Maintainers

A project maintainer may be one person or a few. They are loosely aware of the whole project, keeping track of the ongoing, and are responsible for inspection, maintenance, and repair of equipment. They are also in charge of building source code for binary package distribution and reviewing the project and making sure that it is merged promptly. They are also in charge of directing the developers and reviewers making sure that their communication runs smoothly.

• Contributor

Anyone can be a contributor, as merely commenting on a project, pulling a request, or simply adding value to the project qualifies one as a contributor. Giving valuable insight and feedback is the role of a contributor in an open source project.

• Commuter

An open source committer is a person who has made major input in the development of the project and therefore deserves a separate distinction.  The committee has the mandate to modify the source code of the project’s software that will be used in the final project’s release.

Using leadership roles is a healthy way to promote growth and increased participation in your projects and recognizing people who put extra effort into the project is motivational to the members.

3. Formalization of leadership roles in open source projects

Leadership takes the most important role in the governance of these communal projects. While running a small project, formalizing leadership roles can be done by easily adding their names to the contributor’s page. However, a complex project requires more work. Creating a website and adding a team page or a list of contributors can be one way of formalizing leadership roles. A team with an active contributor committee can volunteer to form maintainer teams or subcommittees where they can address issues like security, and triaging community. Also, one should try holding meet-ups for the leaders to discuss certain issues and have the public listen or ask questions. Engaging the public is a way of increasing contribution to your project.

Documenting the leadership roles and offering guidelines on how one can get a chance to either be a maintainer, contributor or committer should also be on your to-do list. Tools like vossibility have got you covered when it comes to tracking the performance of each member hence making it easier to identify outstanding efforts.

4. Delegation of commit access

While many people argue that committed access should be given to all contributors, I chose to differ from this mentality. A committer is a crucial distinction that should only be given to contributors with exemplary dedication to the project. Committers also have the access to source codes and can modify them affecting the final project’s release. Therefore one should be careful about who to access as they may as well sabotage the whole project.

5. The main governance structures used in open source projects

There are three main governance structures for open source projects. They include

• Benevolent dictator for life (BDFL)-This is a title given to leaders of a small open source project. This structure dictates that the leader (usually the project founder) holds the final verdict over any disputes or arguments in the community. This structure is mainly applicable to small projects only.
• Meritocracy –this structure stresses the point that good ideas can come from anyone or anywhere, it brings to light the notion that the best work rises to the top regardless of the person contributing it. Meritocracy is the most used structure of governance as it motivates the members to work harder on the project as the chances of rising to the top are open and performance-based. Apache foundation is a form of a meritocratic structure.
• Liberal contribution –under this structure, influence is measured by the amount of work you have put into the project. The people with the most work, hold the bargaining power in decision-making. Decisions are made through a consensus rather than a pure vote, where only the major issues are addressed and discussed. Examples of companies that used liberal contribution are Node and rust.

One can choose to use any of the above structures depending on the complexity of your project.

6. Are documents a requirement for launching your project?

There is no stipulated time for writing down your project’s governance, but waiting until the project community is in a good place is a wise choice as then it will be easier to draft the documents. Writing brief and precise guidelines about your expectations of behavior, and how you expect the contributors to carry themselves are docs that you could draft earlier.

If you are taking part in a company’s project, it is wise to have a word with them before the launch to set things straight about how they expect you to act and make decisions after the launch and in the future days of the project. You may also include specific things that the public should expect or not from the company after the launch of the project.

7. The effect of corporate contributors on an open source project

When open source projects become successful, they are used by many people, companies, and organizations, a company may end up endorsing a project as a component of a commercial offering. As the project grows further, professional contributors tend to join in. These contributors are paid, and it may make the unpaid contributors feel inferior. However, there should not be any special treatment given to the paid contributors over the unpaid ones, as both insights are beneficial to the project. Seeking to maintain your project conversations concentrated on the contributions and not the motives that drive the contributors should be your ultimate goal.

8. Are legal entities essential while financing your open source project?

No, you do not need a legal entity to support your open-source project. Creating a commercial business is as simple as just setting up a C CORP or LLC if you are based in the US. If you wish to collect donations, you can create a PayPal account or a stripe account and the money won’t be tax deductible, except for those who qualify for nonprofit.

However, if you qualify for a nonprofit, you can find a fiscal sponsor who will accept donations on your behalf in exchange for a share of the same. Software Foundation, Apache Foundation, Linux Foundation, and open collective are all organizations that offer fiscal sponsorship services for open source projects and can be of help.     

The post Leadership and Governance of Open Source Projects appeared first on CONTRIBUTING.md.

Why look for financial support?

Open source software is designed to be shared, modified, and used by the community of developers. Since the code is usually developed in a public place, anyone can contribute to it. This is accessible to anyone, and you can make changes to the code and then submit them for review. If you add valuable features to the open source software, you may be accepted.

Most developers engage in open source work for voluntary purposes. For instance, you may already have a full-time career but have the skills to contribute to open source in your free time. Some people also contribute to open source work as a hobby, while others like the level of satisfaction it brings. 

Though open source work can seem like free work, contributing can help one gain certain benefits. For instance, it can make you feel closer to the open source community or even help you learn a new skill. You may also earn some external rewards like potential returns in the future due to your contribution to open source work. This can help you get profitable opportunities later in life. 

If you are a developer with a genuine interest in coding, you can contribute to open source work and look for financial support. Seeking financial support while working on open source projects can help you meet your needs. For instance, it can help you cater to your family’s daily needs or even pay a debt. If your main aim of engaging in open source work is to get paid, you can either look for organizational funding for the open source project or fund your time as a contributor.

How to fund your own time as a contributor

Open source software sustains itself through contributions from developers all over the world. It has a very strong community. Though you may not be able to charge money for open source work, you can get paid by funding your own time as a contributor. Many companies often depend on open-source projects for their day-to-day tasks. If your employer uses the open source project, you should talk to them. 

Once you talk to your employer and start maintaining the open source project, you may get compensated for your work. If you choose to start an open source project while you are still an employee, you should ensure that you comprehend the company’s policy regarding open source work. 

If your employer does not use open source but uses Python, you can still talk to them and get paid. Though you don’t necessarily have to make cash from your own project, contributing to the existing project can help you get paid.

In case your employer does not prioritize open source work, think about looking for another employer that does. Some large companies often employ people who can work on open source. Research can help you come across company websites that show their involvement in open source. Such companies include PayPal and Netflix. You may also come across open source projects that have issues that need to be fixed by developers. Making useful contributions to a company’s open source projects is a great way to get paid.

How to find funding for your project

If you already have an open source project you have been working on, you can look for funding for it. Monetary support can help the project develop. For instance, it can help cover the cost of running the open source project and also give you extra cash to invest in new ideas. 

You can easily get funding through a crowdfunding campaign if you have a reputation in the open source community. This concept has been in existence for a while, and it has helped many developers fund their projects. It is a valid option that you should consider exploring since it has few conditions.

Certain organizations also give developers a particular sum of money to help them fund their business ideas. You can start looking into software foundations that offer this. With grants, you may receive the cash even when you don’t create a legal entity for the open source project. Some of the options that can help include the Python Software Foundation and the Sloan Foundation.

You can also start getting money by offering paid support. Since you probably have enough knowledge about the codebase, you can offer consultancy to companies that would like to utilize your project. This can help you keep the open-source project going. If you have extra functionalities or features, you can also charge money for them. 

How to build a case to get financial support for your project

Have you identified a potential funder for the open source work? If yes, you must come up with a compelling case that can help you get financial support. As you present your case, think about the usefulness of your project and try to envision it in the future. You can convince the funder that your project is important by gathering evidence such as stating if there are some popular people currently using it. 

Try to explain to the funder what value the project has to them and state how the funding will help the project. Before approaching a funder, you should also research to find out whether they have requirements for disbursal.

Conclusion

Though open source work may be voluntary, you can actually make money from it. If you have established an open source project, you should assess the specific ways you would like to get paid and start monetizing it. As you approach a funder, remember to be creative and help them understand what value the project can bring to them. Even if you don’t get funding immediately, do not lose hope but continue researching more options.

The post Getting Paid for Open Source Work appeared first on CONTRIBUTING.md.

What is the importance of having a code of conduct?

When working on a certain open source project, every participant should understand what is expected of them. That is where a code of conduct comes in. This is a document that outlines the rules that the participants in the open source community should follow. It is important since it can help you create a good image in the community.

Working without a code of conduct not only affects the participants but can also affect you over time. This is because if the participants have an unproductive attitude, it can leave you feeling drained. 

A code of conduct can empower you to facilitate constructive and healthy community behavior. It ensures that every participant behaves in a respectable and impactful manner. It can also help you take action when a participant does not abide by it and minimizes the chances of anyone within the community getting fed up with the open source project.

How to establish a code of conduct

Since most open source communities already have a precise code of conduct, you can use some of them as guides to come up with a code of conduct for your open source community. Some of the communities that you can borrow ideas from when making a code of conduct for your open source community include WordPress, Mozilla, Microsoft, and Google. 

You should establish the code of conduct immediately when you create the open source project. As you create it, ensure you clearly state your expectations. You can explain where it takes effect, for instance, on community activities or on issues. Ensure you explain who it applies to. It could apply to the members of your open source community.

Many participants of open source communities who feel underrepresented have been fighting for inclusivity. A code of conduct is one of the useful instruments that help bring change to such communities. It is not only a tool for empowerment but also helps call out bad behavior. You should therefore highlight how an open source community member can report violations. Do not forget to explain what happens if a participant goes against the code of conduct. 

You should also ensure that the code of conduct is easy to locate. You can either have a specific page on your community’s website that outlines everything regarding the code of conduct or have a Code of Conduct.md file in your project’s repository.

Deciding how you are going to enforce it

As the leader of an open source project, one of your responsibilities is to ensure that there is safe and fair enforcement of the community’s code of conduct. Coming up with a code of conduct that cannot be enforced can send the wrong message to the open source community. It can imply that the values of the code of conduct are not important. 

Take your time to explain how you plan on enforcing the code of conduct to show that you will take action in case of a violation. Doing this can also reassure the open source community that any complaints raised will be reviewed and that the process will be transparent. 

Ensure that your participants have a way of reporting a violation of the code of conduct privately. For instance, they can do this by using a specific email address. Also, explain who will receive the report. You can also mention that as a community leader, it is your obligation to respect the security and privacy of any participant that reports a violation of the code of conduct. 

Enforcing the code of conduct

Though open source communities set a code of conduct that participants should follow, some people violate it. As the leader, you have to address negative behavior. Take your time to gather evidence and learn everything about the situation. Consider the voices of different community members. 

You can go through different conversations and comments online to try and understand why they may have violated the code of conduct. Once you have all the evidence, you can now take action. Think about the best way to deal with the situation as you consider how your action will affect the behavior of the rest of the community members. 

If, for instance, it is their first time, you can warn them publicly. Explain how their negative behavior may have impacted others in your open source community. Alternatively, you can contact them privately, especially if personal details are involved. If you do this, let the participant who reported the violation know that you warned the offender. 

If the person does not take the warning seriously and continues to violate the code of conduct, you can ban them temporarily. If they don’t change, a permanent ban from the open source project would be the right action. 

What are your duties as the maintainer?

As a maintainer, your duty is to come up with the guidelines that every participant must follow. You also have to enforce those guidelines according to the code of conduct. Ensure you review every complaint thoroughly before determining whether it is a violation of the code of conduct or not. Identify the problems in your community even if there is no violation and aim at shaping the community values of the open source project.

An open source project depends on the collaboration of members from different parts of the world. Since participants have different backgrounds and views, it is important that you establish a code of conduct as the community’s leader. This can help every participant understand your standards of ethical behavior and expectations. Though enforcing a code of conduct is not always easy, it is important since it can help the community thrive.

The post Your Code of Conduct for Open Source Communities appeared first on CONTRIBUTING.md.

Importance of measuring.

When data is used correctly and wisely, it can help an open source maintainer to make better decisions. With well-interpreted information, you can be able to understand how project users react to new features and discover where new project users come from. Also, with more information, you can choose whether to support a case or functionality, quantify the popularity of your project, gain insight into how your project is being used and be able to raise funds through grants and sponsorships. 

Even though project popularity is important, it isn’t everything. Open source maintainers get into open source for various reasons and if your goal is just to display your work then metrics aren’t that crucial to you. Sharing your code and having fun while at it will do the job.

Make your project discoverable to others.

People need to know about the existence of your project if you want them to use it or contribute back to it. For instance, if your project is hosted on GitHub, it is possible to see how many people have landed on the project and where they came from, by checking your project’s traffic page under “Insights”. 

On the project’s page, you can also see the total views of the page (which shows you how many times the project has been viewed), referring sites (which help you to know where your visitors came from online), total unique visitors and the popular content of your project (specifically shows you where visitors go on the project and this is classified by unique visitors and page views).

GitHub stars can also tell you how popular your project is and how many people are noticing your work, however, it doesn’t necessarily reflect on the usage of your project. Additionally, consider working on your project discoverability in other platforms like PageRank, Google, referrals from other websites and open source projects and referrals from your project’s website. 

Usage of your project.

After people discover your project on the internet, are they using it? It is crucial to know what people are doing once they’ve discovered your open-source project. If package managers like RubyGems.org and npm are used to distribute your project, it is relatively easy to track your project’s downloads. Note that each package manager uses a distinct definition of “downloads” and downloads don’t necessarily mean usage or installs but they are still important in helping you with comparison. 

Platforms like Libraries.io are great for tracking usage statistics across commonly used package managers. Again, if your project is on GitHub, on the “traffic” page, the clone graph can show you how many times your project has been cloned, total clones and unique cloners on a specific day.

If you discover that your project’s usage is low in comparison to the number of people who have discovered it, then there are two potential issues to look into. One of the issues could be that project isn’t converting the audience or the audience attracted isn’t the right one. For high conversion, your project must land on the correct platforms with people who actually need or will benefit from it. Once you discover that your project is being used, figure out what the users are using it for.

User retention and contribution.

Now that people have discovered and are using your project, ask yourself if they are contributing back to it. It is useless to have a popular project (which has many users) that is not supported (inadequate maintainer time to meet demand). You need to have people pitching in. User retention is equally crucial as current contributors will eventually leave therefore, you need to have a steady inflow of new contributors. 

Various community metrics need regular tracking and some of them include metrics like the total count of contributors and the number of commits from each contributor. This metric lets you know how many contributors your project has and who’s more or less active in the project. If your project is on GitHub, you can view this information on “Contributors” under “Insights.”

Another metric to keep an eye on is first-time, repeat and casual contributors. This information lets you know if you’re getting new contributors and if these contributors are becoming regulars. Casual contributors are considered those with a low number of commits and without new contributors, your project’s community can become stationary.

Also, consider tracking the type of contributions your project is getting, for instance, typos, bugs, commits or commenting on an issue. 

The number of open issues your project gets is also a crucial metric to track. If your project is receiving an increase in the number of open issues that means users care enough about the project and they are interested in it thus they’d like to see an improvement. However, if these numbers are too high, it is advisable to get help with code reviews and issue triaging.

Maintainer competency.

Are you responding to the contributions your community raise? Always ensure your project’s maintainers are competent enough to handle the bulk of contributions received from users. Unresponsive maintainers are a hindrance to successful open source projects because if a user submits a contribution and doesn’t get any feedback, they get discouraged and eventually leave. According to research from Mozilla, responsive maintainers encourage repeat contributions, which is what you want for your project. 

Track how much time it takes for you to respond to contributions and note that responding doesn’t always mean that you have to do something. Sometimes a response like “Thanks for your submission, we will review it soon” is enough to make the user feel heard.

Using metrics to understand people.

Lastly, the metrics discussed above can help you learn more about your audience thus building an active and thriving open source project.

The post Open Source Metrics appeared first on CONTRIBUTING.md.

The legal implications of open source 

Sharing your creative work within the legal umbrella of intellectual property can be both an exciting and rewarding experience. On the other hand, it can also mean a bunch of legal things you were not familiar with and didn’t worry about previously. The following are some of the legal disclaimers that a person must be cognizant of in relation to this article:

1. Legal Disclaimers

Legal disclaimers enable the open source projects to be able to be used due to the license granted by the author of the source code that enables and facilitates the protection of contributors and removes the possibilities of arising warranties and disclaiming liability for damages resulting from the usage of the projects. 

Operating an open source project, like any other human endeavor, involves uncertainty and tradeoffs. The legal questions arising may differ in its own uniqueness and therefore, you should seek help from legal experts and consult your retained or your own legal counsel to address this. The same applies to companies. 

2. Licenses

License is a permission granted by a qualified authority permitting a licensee to do something that would otherwise be prohibited by law. This also includes a permit. 

3. Permissions

This is an authorization or formal consent from someone in authority. With regards to this article of open source, some projects are used with the permission of Django Software Foundation and individual contributors.

The importance of legal framework of open source

Any work that falls under intellectual property including creative works such as writing, code or graphics is under copyright laws by default. The law protects you as an author of the work by making you have a say or a stake in what third parties can do with it.

In a general sense, this means that nobody else can use, distribute, copy or modify your work without being at risk of take-downs, shake-downs or even litigation in some cases if all attempts of depositions and alternative dispute resolution mechanisms fail including arbitration.

As stated earlier, permissions are important aspects in open source. This is because open source being an unusual situation, the author expects that others will use, modify and even share the work. But because the legal default is still exclusive copyright, you need a license that explicitly provides for these permissions aforementioned.

It is also noteworthy that if you don’t apply for an open source license, everyone who is a party to your project in terms of contribution becomes an exclusive copyright holder of their work. This in simpler terms means that nobody can use, copy, distribute or even modify their own contributions and it is not only limited to them but includes you too.

Your project may also have dependencies with license requirements that you were not cognizant of or aware of. Your project’s community or in some instance your employer’s policies, may require your project to use specific open source licenses. Some of the latest versions of these licenses includes the General Public License (GPL), version 3 of this provides for a clause that forbids the payments of royalties on copies of the open source software. Another type of license is the Berkley Software Distribution (BSD), which has an important source of Unix development. Unix is an operating system which is analogous to DOS and Windows that supports multiple concurrent users. 

The question of whether public GitHub is an open source

It is important for you to note that GitHub is not a law firm and as such does not provide legal advice. When you want to create a new project on the GitHub platform, you are provided with options to make the repository public or private.

Making your GitHub projects differs from licensing your projects. This is so because public projects are covered within the purview of GitHub’s terms of service, which allows others to view and fork your project, but does not have permissions. In other words, your work comes with no permissions.

If it is your desire that others should use, distribute, modify or generally contribute back to your project, you need to include an open source license for this to be feasible. For instance, a person cannot legally use any part of your project in GitHub in their own code, even if your code is public unless and until you explicitly give them the right to proceed to do so. Failure to acquire gives a person this right and they proceed to use your code, they will be held liable in law and you will be compensated damages.

Licenses that protect your projects

Currently, open source licenses are standardized and easy to use. It is as easy as just copy pasting an existing license directly into your project. 

The most popular open source licenses include;

1. MIT License

This is a short and simple permissive license with conditions that only permits preservation of copyright and license notices. 

1. Permissions 

• Private use 
• Modification purposes
• For commercial use
• Distribution purposes

2. Conditions

• Must include license and copyright notice

3. Limitations

• Liability
• Warranty

2. Apache License 2.0

This is a permissive license whose main conditions require preservation of copyright and license notices. The contributors must provide an express grant of patent rights. With relation to modifications, licensed works and larger works, it may be distributed under different terms and without a source code.

1. Permissions

• For patent use
• Private use
• Commercial use and distribution
• Modification use

2. Conditions

• State changes
• License and copyright notice

3. Limitations

• Warranty
• Trademark use
• Liability

3. GNU General Public License v3.0

Permissions of this license are conditioned on making available source codes of licensed work and modifications by including larger works using licensed work under the same license. Just like Apache 2.0, contributors must provide an express grant of patent rights.

1. Permissions

• Commercial and distribution use
• Modification use
• Patent use
• Private use

2. Conditions

• Same license
• Disclose source
• License and copyright notice must be provided
• State changes

3. Limitations

• Warranty
• Liability

Any project created on GitHub will require the author to add a license. This does not necessarily mean that you’re under an obligation to choose a license. However, without one as such, copyright laws will apply and you will retain managing rights to your source code. That is, no one may reproduce, distribute or create derivative works from your source code.

Choosing a suitable license for your project and examples of appropriate project licenses.

MIT License is usually the best license to go for based on its applicability and usability. It allows any person to undertake anything within it as long as you retain a copy of the license, including copyright notice.

Picking the right open source license usually depends upon the author’s objectives. Your project will most likely have dependencies. For instance, if your intent is open sourcing a Node.js project, there is a high probability library use from the Node Package Manager (nvm). Each library depended on will have their own open source license. If the licenses are permissive in nature that is they give the members of the general public permission to use, modify, and share, without any condition for down streaming licensing, a person can therefore use any licensing they wish to applicable in their work. The most common permissive licenses include MIT, Apache 2.0 and Berkley Software Distribution (BSD).

Contrary, if your dependencies are of a strong copyleft; (these are permissions given to the public subject to condition of using the same downstream license), then your project must use the same license throughout. An example of a strong copyleft license is General Public License v3 (GPLv3).

It is also prudent to consider the communities that will use and contribute to your project. The following are questions for your own undertaking with regards to your project:

• Whether you want your project to be used as a dependency by other projects
• Whether you want your project to appeal to large businesses
• Whether you want your project to appeal to contributors who do not want their contributions to be used in closed sourced software

Furthermore, companies differ with their specificity of licensing requirements for its open source projects. Some companies may require permissive license, another company may require a strong copyleft license or another may require a particular licensing strategy that addresses certain needs related to standards, transparency or even social responsibility. 

Circumstances that may make you to change project licenses

It is anticipated, expected and foreseeable that circumstances change sometimes hence prompting projects to change their licenses.

This may arise out of the possibility that as your project grows so will the dependencies or the users, or your company may review the strategies any of which could require an application of a different license. There are three factors that are considered when adding or changing the project’s license as provided down below:

1. Complications

The compatibility and compliance of who holds copyright usually gets complicated. This is because switching to a foreign but compatible license for new contributions is different from relicensing an already existing contribution. This again will need you to involve your company’s legal team.

2. Project’s existing license

if the current existing license is compatible with the new license you intend to apply, then you can start using the new license. This is because compliance with terms of the old license will be compatible with terms of the new license. For example, if a permissive license is in use, a similar license with more conditions can be applied so long as you retain a copy of the original permissive license and any associated copyright notices.

3. Project’s existing copyright holders

In an instance whereby you are the sole contributor, you are held as the project’s sole copyright holder. Therefore, you can change to your preferable license you or your company desires. If there are many copyright holders, you need agreement from everyone with a stake in order to change the licenses

Additional contributor agreements

There are vast majority of open source projects and an open source license is flexible to cater for both inbound that is contributors and outbound that is contributors and users license. Therefore, it will not be necessary for an additional contributor agreement.

An additional contributor agreement also known as Contributor License Agreement (CLA) creates administrative work for the project maintainers. The amount of work to be added usually depends on the project and implementation. Some of the situations whereby a person may consider an additional contributor agreement includes:

• In a situation whereby your legal team want all the contributors to expressly accept to contribution terms by signing online or offline because they may be of the view that the open source license is not enough. An example of an easy additional contributor agreement is the JQuery individual contributor license agreement. An Open JS Foundation comprises of 32 open source JavaScript projects inter alia, Appium, JQuery, Node.js, webpack.
• When you or your legal team want developers to represent that every commit they make is authorized. 
• The project incorporates an open source license not including an express patent grant and you need it from all the contributors in existence some of whom may be attached to companies with large patent portfolios that may be used to target both you and the project’s contributors and users. The Apache Individual Contributor License Agreement may be used as an additional contributor agreement to counter this.
• When your project is under a copyleft license and you want to distribute a proprietary version of the project. The MongoDB Contributor Agreement may aid in this instance. It is a short form that allows you to easily pull requests against GitHub usernames that already signed the agreement.
• When your project might need to change licenses in its lifetime but you want the contributors to agree to this in advance.

A CLA assistant minimizes contributor distraction as it performs functions such as commenting on each opened pull requests, updates the status of a pull request when the contributors agree and automatically asking users to re-sign the CLA for each new pull request.

Company legal team scope, powers, framework and functionality

Before sourcing any project, your company’s legal team should be aware of this. This applies to personal projects as well. For personal projects an employee IP agreement with your company should be in place as this them oversight over your projects if they are related to the company’s business or you intend to use the company’s resources. The company grants you permission through the employee IP agreement or in some instances a company policy.

In a situation whereby you are open sourcing a project for your company, it is mandatory that you let them know. This is because your legal team will need to review the policies for what open source license and additional contributor agreement will be preferable based on the company’s business operations and expertise that ensure your project is in compliance with the licenses of its dependencies. Some of the things in consideration are:

• Third party material. Choose a license that is compatible with 3^rd party open source licenses. If it is not compatible due to contrasts between parties, ask the third party maintainers to add an open source license.
• Trade secrets- Is there information not to be disclosed to the public?
• Patents. With relations to public disclosure.
• Trademarks. The project’s name should not conflict with any existing trademarks.
• Privacy. Does the project involve data collection on users?
• Employee contribution policies. Consider a policy that species how employees contribute to open source projects.
• Compliance. Awareness and process can aid to avoid lawsuits.
• Patents. Open Invention Network provides a shared defensive patent pool to protect members and enables them to explore other alternative patent licensing.

Conclusion

Open source provides control, training, security, stability and community that inspires users and developers to from and grow their companies. The legal aspect protects everyone involved in the open source process and procedures as discussed by the above article. Therefore, it is encouraged to carry out open sourcing as the law provides a path, shield and justice to all persons. 

The post THE LEGAL SIDE OF OPEN SOURCE appeared first on CONTRIBUTING.md.