What A Developer Needs To Know About Open Source Software

DZone 's Guide to

What A Developer Needs To Know About Open Source Software

Know, and be a good steward of, the unwritten rules of the open source community and pay attention to the details of licenses.

· Open Source Zone ·
Free Resource

To gather insights on the current and future state of open source software (OSS), we talked to 31 executives. This is nearly double the number we speak to for a research guide and believe this reiterates the popularity of, acceptance of, and demand for OSS.

We began by asking, "What do developers need to keep in mind when working with OSS?" Here's what they told us:

Community Best Practices

  • Open-source software may not be a mature, end-to-end solution. They might have to invest in figuring out how things work with other tools or at scale. In case there are gaps in documentation or testing, they should be comfortable with interacting with the community. In fact, welcoming open-source communities are often a better choice. 
  • A developer's ability to contribute to open source projects is potentially limited to their employer, which is an issue and something that needs to change. We are starting to see some tech companies change their mind on this. GitHub open-sourced their balanced IP agreement, which is a far more, as the name suggests, balanced approach to allowing and fostering open source technologies. From a tech perspective, developers need to embrace open source and start to contribute to open source projects that are of interest to them
  • See the IBM open source way. You will be more valued if you have open source skills. Make progress, be productive, understand how to work in any open source community productively. 
  • Use and develop using open source versus other solutions if you’re not building something flaky. If you have a problem, engage with the community on IRC and Slack channels. The community is receptive to newbies. Share your achievements with the community. 
  • The developers need to possess the proper expertise that allows them to innovate and contribute to the development of the software while remaining a collaborative team player with the rest of the community. 
  • Don’t hesitate to speak up and communicate. Do everything by following examples. Communicate. Don’t be afraid to ask questions. 
  • They should keep in mind that they're coding on the backs of giants. Or rather they're coding on the backs of the thousands of developers that came before them. Many of us owe our career to the opportunity that open source provided us. 
  • Leave the project better than you found it. It is your responsibility as a beneficiary of the code is to help improve it in some way. This is how it improves for everyone.
  • Know the source of the code. Make sure the project will be around. Double check licensing. See if the community is healthy. 
  • Developers should remember they are part of a community. The projects they are working on don't belong to a single person it’s all part of the open source community. Developers must be open-minded, accepting that everything they are doing will be public, so they can fully receive feedback that comes from the community. People are the most important part of the 0pen source community.
  • Developers should let the community know about problems or shortcomings in a project! Even if you don’t have the time to build a solution to a problem in the open source software yourself, the people who work on projects are eager to hear your feedback. Don’t be shy about reaching out to suggest improvements or share a perspective based on real-world usage. This information is invaluable to open source developers. 
  • They need to keep in mind that the people writing that software are doing what they can to keep it working and to support it, probably on their own time. Your use of free open source software does not entitle you to demand the level of support you'd get from a commercial vendor.  If you feel strongly enough about the quality of the package, become a committer and help improve it. 
  • We challenge our developers to solve a lot of problems in-house and reduce dependency on open source software. The idea is to inculcate the culture that OSS does not solve all the problems. Our developers use OSS with their eyes open to the fact that they should track and use open source software responsibly, track the updates to the software frequently and incorporate patches as soon as they are available. Our developers are also enthusiastic open source contributors, from starting their own open source projects to contributing code to other open source projects, developers stay up to date on the happenings in the open source ecosystem.


  • Two key factors that developers should consider before adopting an open source product are the strength of community and the license terms. A lot of the factors that make open source attractive rely on an active community – check the mailing lists, GitHub, etc., to ensure a product you are looking at has a strong and active community. Different organizations have different tolerances for different types of open source licenses; be aware of your organization's policies and get advice if you need it. 
  • GitHub is a good place to get packages, pose questions, and get advice. Read up on previous uses. Always read the licensing. Consider taking a package with fewer features that are more open. 
  • Understand the legal implications of using open source code. Read the licensing text. Think about the implications of the indiscriminate use of code. Talk to your legal team first. 2) Understand the ecosystem. OSS can be free, but you need to participate in the community. Don’t blame builders of code with bugs because they’re building other things as well. If you find a bug, report it. If you’re able to fix the bug yourself, do it and help the community. 
  • First and foremost, this software is coming from humans. In many cases these projects are labors of love, worked on when someone has spare time. Encourage your company to dedicate time and money to supporting these projects. If your coffee budget is larger than your Open Source support budget, you may want to talk to finance! From a reuse perspective, it’s imperative that you respect the license that the author selected. If you aren’t able to do so, you shouldn’t use the component in the first place. Understand your company’s expectations and policies and work within them to simplify compliance. Help other developers with this task as well since there’s still a lot of folklore and gaps in knowledge regarding Open Source licensing. 
  • Watch for the LICENSE files in GitHub repositories and the copyright headers in individual files.  Respect the licenses, try to keep the copyright to your contributions, and remember that open source has survived for over 20 years thanks to hard work and relentless advocacy: it's not a natural right, it's a clever hack!


  • Your code, once released, is open source forever; you can never recall your code once in the public domain. 
  • Have a bill of materials for everything you build. You can integrate components today with no known vulnerabilities but there will be vulnerabilities sometime in the future. Understand this and take responsibility for ensuring the security of the components you build. Know that accruing technical debt will require time and money whether you’re using first or third-party code. Layer security on top so you are able to tell what version of each open source code you are using. Stay open-minded about technical debt – don’t skip more than one major update. 
  • Operability of the stack. Start as a small experiment but when you see commercial viability go back and look at the hardness and scalability of what you’ve built. You need a good management solution to what you build. Manageability of requirements. 
  • Be careful taking an obscure project. Try not to go off of the mainstream use for a project or you may end up on a dead end with no support for what you are trying to accomplish.
  • Developers are often not fully aware of the company’s needs. For example, they need to solve a specific software development challenge and look for the respective feature. Once they’ve found it, they embed it and consider the problem solved. However, there might be challenges in technical operations or legal compliance that they do not even think about. For example, just because you as a developer are confident the open source tech works fine, since all unit tests are green, you cannot be certain that it will still work under production usage conditions, when the company’s business actually depends on its reliability. This is why it is mandatory to get IT executives approval before basing a crucial part of a solution on open source.
  • Find the right balance between not invented here. Use open source commons and what you find on GitHub as well as innovating. Software can’t defend itself against big changes. Pick dependencies wisely and maintain it. Be clear about interface stability. Know when it’s appropriate to depend on something.
  • Don’t just choose tools or technology generations because they are “cool”. Evaluate fitness to purpose and whether the benefit of choosing something new and shiny outweighs the potential for getting injured by its sharp edges. These days, developers are often more like system integrators: writing code to knit together a variety of open-source systems. But ultimately the developer is still responsible for system quality and reliability whether or not that system is built on top of someone else’s code. You can’t outsource that.
  • People expect that the software they use is both intuitive and easy to work with. Therefore, it is critical that the design of user interfaces and the user experience are optimized to encourage maximum participation and use. This is true whether you are using open or proprietary software, and regardless of the platform, the software is installed upon.
  • Enterprise developers, within businesses, have to understand that open source software is very innovative but, can be rough around the edges. Understanding the business needs and outcomes can dictate what open source software is used and how much of the resources are needed. Also, all tech comes with debt in an enterprise company. So even if it’s a pre-production prototype or an actual in-production solution, all of these come with debt that must be paid in the forms of: 1) People/Resources; 2) Money; 3) Time. Most of our customers that have embarked on open source only, and alone, have come out the other side with at least one to two failures before they figured out the right mix of: 1) What tech debt they were willing to take on, and 2) How much they were willing to reside with outside partners.
  • Developers should approach OSS as if it were an extension of their own code. This means a careful reading of code and tests. Developers should never assume that “someone else” has thought through all the edge cases of problems a piece of open source software was designed to solve. It is usually worthwhile to use and contribute to open source software rather than reinventing the software in a proprietary way. However, this needs to be done with caution as every additional dependency — open source or not — increases the complexity and the attack surface of a project.

Here’s who shared their insights with us:

interview, licensing, open source, open source best practices, open source community, open source licensing, oss

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}