Ask Safia: How do I move from a proprietary software background into open source?

No readers like this yet.
Ask Safia postcard of a pier and water
Image by:

 

Florida Memory. Modified by Opensource.com. CC BY-SA 4.0

Dear 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.

Dear Safia,

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,
Safia

Tags
Careers
Safia Abdalla
User profile image.
Safia is an energetic software engineer with an interest in data science for social good, intelligent interfaces, and great coffee. Follow her on Twitter. She is the founder and fearless leader of dsfa, a professional services startup aimed at providing data science services to small businesses.
More about me

1 Comment

Avatar
Shane Curcuru | May 24, 2016
No readers like this yet.

Both good answers. For licenses, by far the most important point is to HAVE A LICENSE. Some of the github generation seems to not care, but companies and experienced developers alike in the FOSS world know that code without a license is just copyrighted, and the rest of the world has no rights to it - meaning, we're unlikely to contribute to your unlicensed project.

ChooseALicense is a great service. Personally, I like the Apache license. While it's longer than the MIT license, it's the de facto standard for most major new projects that aren't going the GPL route. If you're not a lawyer, you don't need to worry about the extra clauses; the net is that it protects the original author(s) more than the MIT license, and it's slightly more business friendly (because of the patent language). Being business friendly tends to mean that more people will be interested in contributing...

Related Content

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.