At Mobility Labs, we encourage open-source development for many of our social impact projects and work with open-source tools for the best solutions. As part of this work, we regularly hear why partners are uncomfortable with the idea. We want to dispel some common open-source myths that we’ve heard.

Let’s first outline what we mean by “open source development.”

Making code accessible to others on GitHub or a similar platform

For your code to be open-source, you should use a platform for sharing the source code. A few platforms exist for this, but the most popular at the moment is GitHub. GitHub gives you a number of tools to share code and manage the software development process. Even teams that create software in a closed environment use GitHub.

Allowing others to suggest/make improvements in a public space

Your community and users should know what changes are coming to the software and what changes are not. This also allows them to see how responsive a development team is to their needs. This does not mean every change suggested will be built; rather, it means a user could go to the issue page, find someone already pointed out something they would like, and read the team’s response. This is also the place to ask your community for help, accept help, and discuss longer-term roadmaps.

Your code contains a license that supports the organization’s goals

Without a license, it is not recommended that you release code because contributors and your team need to know what is allowed to be done with the software before they can use it. This can be a headache for your legal department to wrap their heads around; however, it is important to use a well-known license to ensure contributors understand the limitations of using the software. The big four are: MIT, APACHE, GPL, and BSD. These licenses protect the software while at the same time allowing others to make use of it.

Now on to the three biggest objections.

“We want to own our platform, not give it away for free”

You can still own your platform–you’re not giving control of it away at all!

There’s more to your platform than just the code–it also includes your data, as well as the service you’re providing to your users. Allowing the code to be open-source doesn’t enable another person or company to instantly be capable of competing with you, as they would be lacking both the data and your organization’s expertise.

For example, if we look at WordPress, which is one of the most popular platforms in the world, its code base is entirely open-source. However, this doesn’t detract from its strongest offering, which is hosting and support through WordPress.com. WordPress also allows users who are technically savvy to contribute back to the platform through the use of plugins and extend the platform in different and exciting ways, while profiting through its services.

“We don’t want people to see our data or how we protect sensitive data, like student data”

Your data will remain secure if you open up your code; you’re not releasing any of your data to the public through open-source code (though you could if it makes sense for the organization). The distinction lies between code and data: Your data drives your platform, but your code can still function without that exact data.

To address this, the architecture of your code base should be split so that the actual data stored in your platform can be configured to use any data required and should be secured according to the requirements of the data itself. Don’t expose any of this configuration, but provide documentation on the type of configuration that would be required.

Moodle is an example of an open-source LMS (learning management system) that shares code but keeps student and teacher data safe on the server. This does not mean there haven’t been bugs or security issues that occur, but the power of open source is that the community finds out about it, fixes it, and then end users (universities, schools, and companies) can roll out the fixes.

Doing this correctly for open source actually makes your data more secure by ensuring the development team is using best practices and that problems are getting fixed. This also allows external professionals to find mistakes and suggest improvements. No one wants to find out their platform was improperly configured or secured and that their data is now public.

“We don’t want any random person on the Internet to be able to make changes to our platform”

An internal, closed-source project would not permit this, and neither should your open-source project.

Let’s describe what would normally happen on a proprietary code base. You have a set of curated contributors who have access to the code base, and they change it according to client requests. These changes include things like fixing bugs, implementing layout changes, and improving performance. These contributors would then have a process that mandates that their code is reviewed for quality and maintainability, as well as a suite of tests that ensure that the behavior as mandated by the client is both met and not changed through platform modifications. Only after quality checks and testing would the modified code be eligible for merging back in with the original code, as well as deployment to production.

On an open-source project, you should have the same level of rigor with your code base. Your code will still require a review process, as well as tests to ensure that no behavior that has already been decided and agreed upon has changed. An emphasis should be made on code maintainability as part of the review process, which would include mandating that thorough tests are included with any contribution. Just because code makes it into the code base doesn’t mean it is deployed right away.

With open source, there is no change in the way you handle your code and its release process; the only change is who gets to contribute to it.

Another example of this in action is likely the browser you are reading this article with right now: Chrome, Firefox, Safari, and about 30 more. (Sorry, Internet Explorer users!) All of those browsers use some version of Webkit, the engine that determines what shows up on your screen and how. Large companies like Adobe, Apple, Google, and Mozilla have been able to leverage contributions from the open-source community to fix bugs, create new features, and improve performance. You can see what code is in the works by visiting their site (Warning: It’s very technical).

This sounds too good to be true

Open source is not the holy grail of software development, but transparency, sustainability, and communication might be. Open source development supports these benefits.

• Transparency. Software development of a custom platform is difficult, more so when stakeholders can’t see what’s going on under the hood. Things can go wrong at any moment. Even projects that appear successful sometimes collapse under poor development practices that were not visible until after delivery of the code. Open-source development ensures everything is out in the open.
• Sustainability. Budgets change, projects get dropped, and software that companies have invested heavily in dies without fanfare. But it doesn’t have to be that way. If the software is serving a need, there may be a group out there willing to continue to develop and use it even if the original investor no longer can. If a stop-gap measure is needed for a temporary budget or a vendor problem, contributors from the community can be leveraged.
• Communication. Communication with your audience and stakeholders is key to creating software that delights. When issues are reported publicly and stakeholders can discuss changes with the community, users and management can adjust to coming changes.

Developers, designers, and subject matter experts decide to work on open-source projects for a number of reasons. To benefit from open-source development, these experts should be attracted to your software.

What can open source do for you?

• Avoid being tied to single vendor for fear no one knows how to make changes to your platform
• Create closer connection with your community
• Attract high-quality talent to work on your software
• Ensure best practices are being followed with external reviews

Working with vendors that create open-source technology

There are a number of software shops that prefer to work on open-source projects, Mobility Labs is one of them. If you have a social impact project that you want to ensure is sustainable and a pleasure to use, contact us.

You can also contribute to a number of projects in a technical capacity or through documentation and issue reporting. Here is a list of some of our favorites that need help with design, development, documentation, and more:

• WordPress – One of the most popular content management systems on the Internet. Used by bloggers, nonprofit organizations, and private companies.
• Quill – Literacy tools developed by educators and technologists.
• Wikipedia – You already know about this one. We are not recommending contributing code, but you can always contribute knowledge