Save time and money with an open-source project (but don’t make these mistakes!)
Saving time and saving money. We’re all trying to do more of that these days. But there’s a right way and a wrong way to get your product to market faster.
I see businesses do it the wrong way all too often. They rush the timeline, and work gets sloppy. In the end, that won’t really save time if the work needs to be re-done.
At Shrine Development, we approach every new project with a framework that we call Build, Buy, or Leverage. (We’ll help you figure out which approach is right for you during our discovery phase). This has helped us save our clients’ time and money on countless software development projects.
With Build, Buy, or Leverage, there are three possible ways to meet your software needs:
1. Build. Write all the code yourself and build your software from the ground up.
2. Buy. There are plenty of commercial software solutions available on the market. One of them might meet your needs entirely, or with minor customizations.
3. Leverage. Start with an open-source project and build upon their code to create something new and customized to meet your needs. This is the one I’d like to focus on today because it’s underutilized among startups and companies building their next app, but it allows you to launch software faster and potentially save you money.
If you’re not familiar with open-source software, let me briefly explain what that means.
Open-source software has its code freely available on the internet.
Closed-source software, on the other hand, is privately owned, often by software development companies or major corporations. The Microsoft Office suite is a good example of closed-source software. The end product is available for purchase, but the code cannot be altered, manipulated, or leveraged to build something else. You just secure the product for its intended use.
Open-source software, in contrast, is publicly available. Depending on the licenses available, you can often use the code without paying a dime to anyone. It’s just free, for anyone, for any legal purpose.
This offers a tremendous advantage over building your own software because the code is already written for you. You just need to integrate it. You can add to the code, change it, and build something new on top of the existing code. Open-source work allows you to avoid having to start from scratch. It starts your project on the 10-yard line instead of the 50.
An open-source project is typically put together by a set of “maintainers.” The code maintainers could represent a company (Facebook maintains open-source software for a project called React, for example) or an independent group of engineers or developers working on a side project. Individuals often launch passion projects as open-source software because they want to share their ideas and work with the world.
When open-source software is maintained by a company, they’re doing it to increase their mindshare within the software development community, which helps them attract and retain the best developers. It solves a business problem, but it also fits into a larger talent recruitment and retention plan.
Not all open-source projects are created equal. There’s a broad spectrum of quality and use cases available. Like Wikipedia, anyone can publish an open-source project. So you need to investigate the source before you use the content.
Where can you find open-source projects to leverage? I like to start on GitHub.com. GitHub is a website that hosts open-source projects. You can view a project’s entire code documentation, check the project’s ratings (which displays stars to indicate the number of other users who like the project), find out how often it’s being updated, and more.
Here are the three steps you should take to determine which open-source software is right for you.
Step # 1: Investigate the Maintainers
One of the potential pitfalls of open-source work is that anyone can publish it. When you purchase a software from an established company, let’s go back to Microsoft Office for this example, you more or less can trust that what you’re getting is from a trusted source. You know it’s going to work.
When you’re evaluating an open-source project, it’s important to look at WHO is maintaining or sponsoring the open-source project and HOW they’re using it.
Start by looking at the companies and developers involved. Who actually sponsors this project? Let’s say you’re looking for open-source software to leverage for a finance project, and you come across code from a project created by Quickbooks. They’re a financial company, so this is probably relevant to their daily operations and they’re likely to be using the software regularly. If you come across software for a video game sponsored by Intuit, however, I’d be skeptical that they’re putting a lot of effort into maintaining that project. It’s too far outside their wheelhouse.
Next, investigate how the project is being used. Try to find out whether the maintainers actually use the project they’ve built and how critical it is to their interests.
Step #2: Social Proof
So the maintainers like their project, but is anyone else using it? Find out if anyone else is actually using the software.
For example, say Facebook publishes an open-source project. Are companies like Google or Airbnb leveraging it for their own projects? Is…anyone?
This is an important signal because it clues you into the usability of the work and its quality. Check the ratings on GitHub, and check the frequency and freshness of project updates. Typically, the more people that like a project and the more often it gets updated, the better.
The frequency of updates is key because open-source projects need frequent maintenance to adapt to rapidly-changing technology. Think about how often you get a software update on your phone, or any apps you have on your mobile device. As users, these often happen in the background without us noticing. But they provide critical upgrades to the security and user experience of those products.
Open-source code needs the same kind of updates to keep up with changing technology, security and usability issues.
#3 Ensure Team/Project Alignment
You might find an open-source project that looks great, but is it great for you?
Make sure your in-house team will actually be able to leverage the project for the specific software or app you want to build. Confirm that they understand the code, and are comfortable with the underlying technology. Don’t force a project on your developers. They need to feel comfortable with the code and how it will be used, or again you’ll end up wasting more time and resources than you save.
When you talk with your team, try to get a feel for the level of effort required to integrate the open-source project. Make sure it aligns with your team and your end goals. If the software you’re building is wildly different from a source project, you’ll spend more time customizing the project than you would have building it from scratch.
It’s also important to check the license on a project before you use it. Often you’ll see projects with a standard MIT license, which is considered the gold standard of open-source. If you see a project with a commercial license, that’s a red flag. Typically software that has a commercial license won’t have as many likes, so you can use that as an indicator but be sure to check the license yourself.
Example – Comparing React vs Ember
My top open-source project for 2020 is React, so let’s use that as an example.
React is an open-source project maintained primarily by Facebook. It’s a framework that makes it easy to create interactive UIs or user interfaces, the front-end of your website (the front-end being what users see when they visit your site). It’s one of my favorite open-source projects right now because it solves an awesome business problem and has a great community of developers behind it.
Let’s take a look at the social proof. It’s liked by 146,000 developers on GitHub, which is a good sign.
Netflix, Instagram, Pinterest, Twitter all use the open-source React software. Those are some heavy hitters. When I see major companies like those using this project, I feel pretty confident that it’s reliable and updated regularly.
Taking a look at React’s docs, you can see that they have a lot of recent updates. If there are no supporting docs on a project or they are extremely outdated, that’s a red flag.
One of React’s top competitors is a project called Ember. Let’s take a look at their qualifications.
Ember JS has approximately 21,000 stars, which is nothing to shake a stick at. Popularity isn’t everything. It’s just one indicator of a project’s viability.
As you can see in the documentation, there are still a number of major brands that use it. And they also have recently-updated docs.
Ember is still a solid project. This is where team alignment is really key in making a final decision about the right open-source work.
Final Thoughts
When you do decide on an open-source project, consider giving back. Remember that many of these are passion projects, and the developers may have used their own time to build something that saved you (in many cases) hundreds of hours or weeks of work. If you can, support their work with a donation to the project. It will not only help maintain the open-source work, but it could allow those developers to build more tools you can use in the future.
If you can’t provide a monetary donation, consider contributing your time to help update the project. This not only helps your own software, which is built upon that open-source work, but it helps everyone else who needs it.
Do you have an idea for an app or software, but need help finding the right open-source work to leverage? We’d love to help. Drop us a line to get started.
