Wählen Sie eine Sprache
I had the pleasure of participating in an open source panel at the 2016 Cisco Live event last month in Las Vegas. Much like the host city, the event was larger than life – huge and packed with energy. For the panel, I was joined by Cisco’s VP and CTO of cloud computing, Lew Tucker; Lauren Cooney, senior director of open source strategy at Cisco; Phil Robb, senior director of networking solutions for the Linux Foundation; and Charles Eckel, DevNet open source developer evangelist at Cisco. We had a wide-ranging conversation about open source and its value to developers and customers, which centered on the theme that participating in an open source project is more social than technical. Some key takeaways from the panel’s conversation around this theme are:
- When joining a community, you need to learn about the culture of the project
- The best way to grow a community of supporting vendors initially is to pick up the phone and present the project to friends
- A key requirement to creating a successful community is to create a healthy, diverse, welcoming culture
- Focus on user needs and adoption first – a developer community will grow from the diversity of ways in which users adopt your software, and vendors will be more interested when they see that your software solves a real user problem.
- Benefit: You get to engage in the community process much earlier and help ensure that the project fulfills your needs.
- Pitfall: You need to learn a project’s culture and show up with some resources of use to the community to have productive engagements.
- Benefit: As a user, you defer payment to the point of value. You don’t have to invest money up front to figure out whether the software will be useful to you.
- Pitfall: Adopting community-supported open source software involves investing time and effort up front.
- Benefit: As a consumer of a successful community project, you have a choice of vendors who can offer commercial support for the project. In addition, you have reduced risk of finding yourself running zombie code in production, if a supplier gets acquired or goes out of business.
- Pitfalls: You end up having to choose from among multiple vendors, and the selection criteria are going to be different from what they would typically be. You end up having to educate your purchasing department about analysing the risk of acquisition. And a poor vendor choice can result in vendor lock-in, if you choose a vendor who has “forked” the upstream code to make a premium product that you come to depend on.