What's The Most Important Part of the Open Source Ecosystem?
What's The Most Important Part of the Open Source Ecosystem?
The community of users and contributors who share their knowledge, experience, and insights to improve collaboration, innovation, quality, and security.
Join the DZone community and get the full member experience.Join For Free
Bugsnag monitors application stability, so you can make data-driven decisions on whether you should be building new features, or fixing bugs. Learn more.
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 you consider to be the most important elements of the Open Source ecosystem?" Here's what they told us:
- 1) Good integration with other tools. Invariably, a variety of tools need to work well with one another in order to accomplish something useful. 2) Having a healthy community. A large set of users exposes the open-source software to a variety of use-cases and thereby drives innovation. 3) Listening to the community. This one is the complement to having a good community. It is important for any open source project to listen to the incoming feedback and address it promptly. 4) Transparency. It is important to communicate to end users that features have been tested thoroughly, those that are in beta and especially if there are any newly discovered bugs or vulnerabilities in the software. 5) Avoid getting locked-in to a vendor. Since the software is open and many users are trying out its features, it is easy for any user/company to know what features work, the roadmap and if it will suit their needs. The open APIs and ecosystem also make it easy in case the user decides a different tool is a better fit for their use-case. 6) Better security features. Since the entire architecture and the code are in the open, the set of security features being supported is easy to figure out, and if something is missing it’s easy to influence the roadmap of the project.
- The healthiest open source projects have a strong level of contribution from actual users, and they typically have a genesis in a practical solution to a big, real-world problem that was solved within an organization. As a commercial product manager, there is always a tendency to favor announceable enhancements that will help drive marketing and sales. Existing users care more about getting bugs fixed, manageability enhancements, and the like. A really healthy open source project has a good balance of people pushing the boundaries with new ideas and features, and people trying to make their own lives better through fixing bugs and nagging manageability issues.
- Open access and comment contributions. Enable start-ups to explore code developed by someone else to quickly deploy their own product.
- A people-first driven community. A culture based on meritocracy. A philosophy of “doers.” If you don’t contribute, people don’t listen to you. “Words are cheap, show me the code,” Linus Torvalds famously said. Share and collaborate.
- 1) Look at longevity – is there a company behind the code, why are they building it, will they continue supporting it, what is the frequency of updates? 2) Active contributor mechanism and community.3) Active forum community for help and support.
- Community. Some projects have good technology but can be difficult to get help. The Docker community, for example, is very strong. This is the value of open source. The ability to communicate directly with the people who created the software.
- The most important element of being part of the OS community is the responsibility of each member to give back. It's important to contribute to the kernel of all our Open Source projects because doing so ultimately gives us a larger scope of features, quality and user feedback from which we can benefit.
- An open and inclusive community is critical--open source software is at its best when real-world users suggest improvements and contribute new features. It’s impossible for the original creators of a project to design perfect software that meets the needs of a diverse set of users. That’s why collaboration is so important in the space and why open source solutions often evolve so quickly; there’s a chorus of feedback and proposed functionality from people using the software in the real world. Cross-community collaboration is important, too. No software project exists in a vacuum. For example, many Apache Flink users also use Apache Kafka to move their data into and out of Flink. It’s best for users, then, that Flink and Kafka integrate seamlessly and can work together to provide a complete solution for developers.
- Brings developers and platforms closer to solutions for problems. Look at how something operates, see the software archaeology. Community, direct relationship with others that created or are working on a component. A big change has been GitHub. Used to be Apache was the home now GitHub is the new software commons.
- The license that powers the project, the community that builds the project and the availability of tooling to interact with the project all are make-or-break elements for a selected ecosystem or project. If any of them isn’t right, it’s very difficult to make the decision to depend on that component. If any change in the future, this can be the action that makes a company decide to move away from that component.
- The important elements of the open source ecosystem are: 1) Community: An open source project’s success is defined by the extent of the community that rallies around it. The community for any successful open source ecosystem needs to be holistic. Not just the developers, but the users of the software must also consider themselves an active part of the community. End users can test the software and report bugs, and they can also contribute to the documentation. 2) Engagement: Once there is a community with a critical mass around any open source project, they must stay engaged and active. They should add value by submitting bugs, writing documentation, tutorials, and answering questions in forums. Successful open source projects provide channels for interaction between different users and between users and contributors. 3) Strategic Direction: Each open source project needs to have at least a few people (or an organization) responsible for guiding the project in the right direction. Without an overarching strategy, open source software risks gradually become irrelevant and losing the community and its engagement.
Usability and Supportability. Historically, Open Source software has been highly functional, but the UX was lacking. There seems to have been a dramatic improvement in usability, but this needs to remain front and center to ensure that OSS can be used by everyone in an organization.
- Keeping track of the bill of materials in your code in an automated way. Know what you are using and where. Know the top level and all libraries. Look at your own apps for vulnerabilities and then look at your customer base with static analysis.
- Open source has gone from the fringe a decade ago to a strategic decision for developers and IT executives. Able to reuse frameworks and libraries. Reduce time to market. A strategy for future directions to not get locked into particular vendors. Looking to open source frameworks and toolsets to abstract away dependencies on cloud providers.
- Linux by far. Rich with the kernel, compiler, libraries, and open JDK.
- The ecosystem only exists because many, many developers are very passionate about coding. They love to solve a problem in an elegant way and then share their solution with others, often in exchange for public recognition (like “Stars” on GitHub). In the past, they used to do that in their free time. Now that companies have understood the value behind this approach, they allow their employees to create/contribute to open source projects during work time. I think this development was key to the rise of the “new generation” of open source that is not primarily driven by ideology but business reasons and personal passion. Clear open source licenses such as Apache and MIT are crucial because they provide a certain degree of legal certainty to companies that consume open source. If this was not the case, there would not be the “demand” for it on a scale that provides the aforementioned recognition or even business, hence the whole dynamic would be crippled. Unfortunately, there are still legal matters around open source that are not entirely solved, and especially patent trolls can be a bigger threat to companies that produce open source because they are more exposed than those that do not provide transparency about their code.
- The people. Like Soylent Green, open source is people.
- In the geospatial world, the open source trend has taken root over the past couple decades, deployed as software sometimes called Free and Open Source Software for Geospatial, or FOSS4G. Using open source geospatial software offers a number of benefits compared to proprietary approaches, including better software utilization, scaling without penalty, lower TCO, better pricing and better-skilled staff, compatibility with modern IT, and project persistence and resilience. The greatest benefit of leveraging open source is the resilience and continuity it builds within your organization. Developing projects in the open provides visibility to each member of your organization. This way, if an employee leaves, another should be able to pick up where he or she left off.
- The landscape of open source software is so large at this point, and it is ever-expanding. Keeping the momentum going is incredibly important.
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.