Concerns About the Open Source Ecosystem
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.
Join the DZone community and get the full member experience.Join For Free
How to Set Up Continuous Integration Pipelines with Drone on Ubuntu 16.04. Get the DigitalOcean detailed tutorial.
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:
- 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.
- 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.
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.
- 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.
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.
- Integrity, stability, and reliability of the packages. You must spend a lot of time researching and testing to ensure a package is enterprise-ready.
- 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.
Here’s who shared their insights with us:
- Anthony Calamito, Chief Geospatial Officer, Boundless
- Jakob Freund, CEO, Camunda
- Pete Chestna, Director of Developer Engagement, CA Veracode
- Julian Dunn, Director of Product Marketing, Chef
- Matt Ingenthron, Senior Director of SDK Engineering, Couchbase
- Stephan Ewen, co-founder and CTO, data Artisans
- Amol Kekre, Co-founder and Field CTO, DataTorrent
- OJ Ngo, Co-founder and CTO, DH2i
- Stefano Maffulli, Director of Community, DreamHost
- Kelly Stirman, CMO and VP Strategy, Dremio
- Konstantin Boudnik, CTO Big Data and Open Source Fellow, EPAM
- Tyler McMullen, CTO, Fastly
- Jeff Luszsz, VP of Product Management, Flexera
- Angel Diaz, V.P. Developer Technology and Advocacy, IBM
- Ben Slater, Chief Product Officer, Instaclustr
- Grant Ingersoll, CTO, Lucidworks
- C J Silverio, CTO, npm
- Mark Gamble, Senior Director of Product Marketing, Analytics, OpenText
- Francis Dhina, CEO, OpenVPN
- Sirish Raghuram, CEO and Co-founder, Platform9
- Neil Cresswell, Co-Founder, Portainer.io
- Lars Knoll, CTO, Qt
- Brad Adelberg, Vice President of Engineering, Sauce Labs
- Giorgio Regni, CTO, Scality
- Dor Laor, CEO, ScyllaDB
- Harsh Upreti, Product Marketing Manager, API Products, SmartBear
- Jean-Baptiste Onofre, Technical Fellow and Software Architect, Talend
- Antony Edwards, CTO, Testplant
- Matt Ellis, Architect, TIBCO Software
- Karthik Ranganathan, Co-founder and CTO, YugaByte
Opinions expressed by DZone contributors are their own.