Ask Safia is the place to go for answers to your open source community-related questions. Whether you are nervous about submitting your first pull request to a project, or wondering how to write effective bug reports, Safia is here to help with practical, detailed, beginner-friendly answers. So what are you waiting for? Ask Safia.
I really want to start getting involved with open source, but I’ve spent my entire development career working with proprietary platforms and software. How will I be able to get started with open source?
Yours, Proprietary in Pennsylvania
Your inexperience with open source tools definitely is not going to prevent you from participating in the open source community. Regardless of the closed nature of the platforms that you’ve worked with previously, you have all the skills needed to be a valuable open source contributor. If you’ve learned a thing or two about documentation, consider addressing documentation issues on projects. If you had experience in QA or testing, you can start off by user testing the software and identifying areas for improvement or for improving code coverage. Valuing your skill set and the nature of the environments that you have worked in is important.
Now, before getting involved with open source, you’ll need to have a sense of what projects you’d like to get involved with. Even if you’ve mostly worked in closed systems, at some point you’ve likely utilized software that was an open source derivative, or that you’ve found an open source solution for a problem you’ve encountered. Projects that you are personally invested in are the best ones to contribute to. You can use resources such as OpenHatch to find projects that you are interested in and that are actively looking for new contributors.
I’ve been working on several Node packages in my spare time and would like to open source them. What license should I use? What should I have prepared before making my code open source?
Yours. Opening Up in Omaha
Congrats on starting to present your work to the public. Before you release your open source project, make sure that you have the following things in line:
- Contributor guidelines: Make sure that you provide documentation on how other individuals can contribute back to the project. If you’re looking for a template, read A template for creating open source contributor guidelines. Your contribution guidelines should outline how users can set up a development environment, style guidelines, release guidelines, and what kind of non-code contributions you are looking for.
- Code of conduct: A Code of Conduct (CoC) represents the standards by which any individuals who join your project’s community must abide. Codes of Conduct help maintain a civil tone in online discussion and create a welcoming ecosystem for new and long-time contributors alike. If you are looking for a CoC template, check out the Contributor Covenant, which has been used across several large and small open source projects.
Now for licenses! The Open Source Intiative outlines a selection of open source licenses from which to choose. If you’re wondering which license to pick out of these, here are general guidelines that I like to go by:
- If I want a license that is permissive and easy for contributors and users to understand, I use the MIT license.
- If I want to make sure that derivatives or improvements of my open source project are licensed under the original terms, I use the GNU GPL v3 license.
If you’d like a second opinion, GitHub has produced ChooseALicense.com, an online platform that allows you to explore different open source licenses and identify their permissions and limitations.
Over and out,