Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Concerns About the Open Source Ecosystem

DZone's Guide to

Concerns About the Open Source Ecosystem

Concerns were far-ranging with the most frequent related to obsolescence, overlap, vendor perception, domination by large players, and consumption without contribution.

· 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’s your biggest concern with the current state of the Open Source ecosystem?" Here's what they told us:

Obsolescence

  • The biggest concern is the obsolescence of a huge chunk of open source ecosystem every year. Many of these software projects become obsolete because there are not enough people contributing to them. Considering there are hundreds of software modules in a decently sized software application, many of which are open source, software developers need to catalog and track all the open source components that are obsolete and are not maintained anymore. Unless this is done, software applications around the world are at the risk of failure at some point due to obsolete code.
  • We are used to a world where we think about interfaces and dependencies. These days, I am not sure people think through interfaces and dependencies. For example, with the Left Pad JavaScript dependency, the developer shut down his GitHub account and it stopped working. 
  • Our biggest concern is most open source projects were designed to solve a “singular” problem. It takes a considerable amount of expertise to architect, build, maintain and support big data applications using off-the-shelf open source software. So many companies go blindly into the challenge and come out the other side disillusioned thinking open source software can help them. As such, we’ve seen an emergence of many articles about how Hadoop implementations are failing. Hadoop is not failing… the open source ecosystem is failing to define what’s required to use open source for business outcomes. We exist, to help customers manage that “technical debt” and give them all the value open source software can provide.

Overlap

  • Too many overlapping products competing against each other. Think about how many OSS Load Balancer solutions exist, or how many OSS Web server solutions exist, or mail servers. ideally, rather than forking an existing product, try and improve upon it, communities should rally behind, and support a smaller number of OSS options. 
  • There are too many competing projects in certain areas and it can get overwhelming for the end user, as there are too many choices with slight differences. Figuring out which pieces of software really work well with each other is hard, as exploratory projects may look more mature than they really are.

Projects Are Not Vendors

  • That too many users view open source projects as if they are software vendors and expect they can just log a defect with the project and someone will have the responsibility to fix it. 
  • People treating projects as vendors.

Domination

  • A lot being dominated by one player. The code might be available and relatively free, but some remains proprietary, so you have to sign an agreement and give up the rights to your code. 
  • Our concern hasn't changed really. In general, the foundation model of open source ensures good governance. The "our company runs the whole project on our own private repository and decide who gets in" isn't great for customers, innovation or industry but has become a popular way of doing things. Overall though, licensing and the right to fork has made open source resilient enough so that if there is a demand, it will get forked under a better model. 
  • Unfortunately, the huge buffet or choices causes developers to start flocking towards solutions that have broad backing in the market rather than necessarily choosing ones that are fit to purpose threatens to reduce the size of Eric Raymond’s “bazaar” to projects sponsored or run by well-capitalized large players. It’s going to be increasingly tough for small, point-solution projects (or vendors) to survive. 
  • Many open source projects don't have a large distributed community around them and depend on a single corporation to make most of their contributions and determine their roadmap. Having an open source license to a huge codebase is not a guarantee of long-term sustainability of the project if most of the knowledge is owned by one corporation. Consolidation of IT giants is also a big issue that needs to be watched carefully: few companies may end up owning all important open source code. Distributed copyright ownership would help mitigate risks.

Consumption Without Contribution

  • Vendors that consume more than they share. There is pressure in the field to open up the closed code. Community and users choose open source vendors that provide more open code and make contributions to support the ecosystem. 
  • My biggest concern is the tendency of companies to use open source systems but not contribute to them.  We have a small team of developers who work on open source entirely and encourage people on other teams who have the time to contribute to what they use because we recognize that the open source ecosystem can only survive if people give back. If maintenance and development are ignored, software systems will falter and fade.

Other

  • The lack of attention being paid to making upgrades when vulnerabilities are found in open source code. The lack of knowledge about what open source code actually makes up your applications. 
  • It remains something the V.C. community wants to invest in because it can be monetized. 
  • Integrity, stability, and reliability of the packages. You must spend a lot of time researching and testing to ensure a package is enterprise-ready. 
  • Misconceptions about security and a lack of acceptance from the enterprise. However, this will change over time. The more adoption, the more enterprise companies who are producing open source and standing behind it, the more the perception of open source will start to change. I also think you need to consider the open source projects that you contribute to or adopt. Not all source code and technologies are created equal and just because it’s open source doesn’t mean it's a viable solution or even a good one! 
  • Every project community has a different maturity level. Sometimes it can be difficult to engage. The Rust community had trouble engaging and did not want to grow. Community management is key to the success of a successful project. Docker has great community management. 
  • 1) The hard part of code is never the code or the technology; it’s always the people. This is the current challenge with open source ecosystems, and it will continue to challenge the ecosystems. 2) We have, as a group, been inconsistent about how we’ve adopted being inclusive of people who aren’t exactly like all the other open source contributors. As one example, the number of women involved in open source is vanishingly small. It’s just too tiny to be useful. We as an ecosystem have to figure out why that’s the case and do something about that. We need to keep pushing forward, and keep making our communities welcoming, friendly, constructive, and not toxic. Those are all people challenges. 
  • There is a lot of trust placed in the open source ecosystem, especially around security. It’s hard for a developer to know how trustworthy a component is from a standard quality level, and from a targeted attack perspective. The expectations for testing, standards, and monitoring of repositories against attacks will increase, and the open source projects will need more resources and expertise in order to ensure this quality level. 
  • Some OSS is backed by companies, and being backed by a company means they have some resources to maintain that piece of software. Meanwhile, some projects are completely grassroots and maintained by a few individuals. Some things open sourced but then completely not maintained and contributed to. Some projects have no changes up streamed by companies.

Here’s who shared their insights with us:

Topics:
open source ,devops ,software development

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}