A co-authored tale about open source by Sara McCombs & Erica Forget
Photo by Safar Safarov on Unsplash
Momma always said sharing is a good thing. From the sharing of toys in adolescence to sharing of responsibilities in my marriage, Momma was always proven right. Open source works along similar lines.
According to Wikipedia, open source is simply a term that denotes anything, be that code or content, that includes open permissions for use. The term originated with software but has expanded beyond those original constraints to include other open content and forms of open collaboration. Open source is a pretty powerful concept as it lowers barriers to adoption and allows ideas to spread very quickly.
If open source is such a great thing, and no one gets paid, how does it survive?
Open source development relies upon goal-oriented but loosely coordinated partners who interact to create a product which is then, in turn, made available to contributors and non-contributors alike. An open-source license allows source code, blueprints, and designs to be used, modified, and/or shared under specific terms and conditions. This allows for end-users to modify a product for their own customization, curiosity, or general troubleshooting needs.
To understand what this means, let's think about your Grandma’s cookie recipe. I mean, it’s a fantastic recipe, but what would it be like with chocolate chips, or orange zest, or bacon? (I’m curious about a bacon cookie.) Grandma gives your her recipe and you knock it out of the park with your own variation (I’m going to assume it was the bacon ones). Your best friend, a professional chef, makes a recommendation to use maple-glazed bacon pieces. To top things off, Grandma asks to try your recipe at her next social gathering because she’s liked your modifications.
In this real-world, and tasty, example, Grandma’s cookie recipe was open source. You tried her original recipe, you modified it, you received professional modification recommendations, and your Grandma even asked to distribute your recipe at her next social gathering. In comparison, a closed source process would have stopped at your Grandma’s unwillingness to share her recipe and even passionate demands against you trying to recreate it.
Everything sounds GREAT! Where’s the bad stuff you are alluding to?
Well, open-source projects allow for collaboration from anyone in the world and from anyone with a sincere interest. This pools talent from a far greater pool than even the largest companies could harness. Now, things are always hunky-dory in open-source world while things are being maintained and documentation is being updated. However, we’re all human and sometimes we don’t want to share our time any more and simply want to stop participating as a whole. What happens then? This is where things go south.
Think about what an abandoned house looks like. At first, you might not even notice much change. By six months, the landscaping is starting to overflow and things are looking pretty unkempt. By five years, things are looking pretty bad. Open source is pretty similar.
Oh, snap. How can I tell if something is being maintained?
You’ve now learned the reality that not all open-source projects are created equal. So how do we find the good ones? The ones that are being maintained and in the land of sunshine and rainbows. Here are just a few points to keep in mind when evaluating an open-source project:
Update Frequency: When was the project last updated NOT when was the last update. How often should a project like this be updated? Does it meet those expectations? Does it look like project development is occurring regularly or at random intervals? Are the updates on weekdays or weekends?
Issues: Having issues isn’t as bad as it sounds. (Unless you don’t ever address them, then it is kinda bad.) However, open issues are great. The project is generating discussion and feedback. Closed issues are awesome. These are issues that someone has actively resolved.
Documentation: Does it have documentation? Does the documentation look like it has been updated? Are there any broken links or missing images? (A bigger red flag than you may realize.) Can you understand the directions?
Number of Contributors / Number of Pull-Requests: Having more people dedicating time and brainpower to a project generally means there is a large community that is able (and willing) to support it. These people could range from beginner to senior level and from technical to non-technical. Having a large community is a great thing for the project's longevity.
Forks / Stars / Watchers / Downloads: All these metrics tell you how popular the project. Just like shopping for any large investment, we rely upon other’s experience with it to determine how well it may work for our situation. Open-source projects are the same. If there is a significant number of forks, stars, watchers, or downloads you can have some confidence that others have found the project to be useful. However, definitely, do not confuse these metrics with quality.
Now that we’ve touched upon a few things to keep in mind when evaluating an open-source project. Feel free to come up with your own indicators of maintenance. Take a moment to browse random repositories on GitHub and see what these metrics say about each one. Did you find one that might be collecting a bit of dust?
Open-source is a powerful tool that provides us access to new ideas and new methods. However, before betting the whole farm on open-source code in your next project, be sure to take a closer look at the metrics.
Sara McCombs is a freelance writer, junior web developer, business owner, and dedicated mother.
After obtaining two degrees in agriculture, Sara has followed her interests and pursued every opportunity to learn and grow. No longer satisfied to work in a career affiliated with her degrees that is simply an amalgam of agriculture and technology, she’s diving headfirst into the deep end of the technology pool by pursuing software development.
When she’s not chasing her daughter around outside, she enjoys a good book, an Americano, and the company of her husband and dogs.
Erica Forget is a web developer who enjoys pattern recognition, is always learning, and refining her craft. Whether in fiber arts, baking, or coding – everything gets better if you document what works and calculate how to improve the next iteration.
While she staying home with her son, Erica has graduated from Dev Bootcamp as a full-stack Ruby developer. She has supported Women Who Code Austin as an Event Lead for the past two years and contributed to Firefox debugger. Erica holds a BA in Humanities from the University of Texas at Austin.