In my first article in a series about open source program offices, I took an in-depth look at what an open source program office is and why your company needs one. Then I talked about how Google created a new kind of open source program office. In this article, I will explain the benefits of having an open source program office.
At first glance, one important reason why non-software development companies are more enthusiastic about embracing open source program offices is that they have nothing to lose. After all, they don’t rely on these software products to generate revenue. For example, Facebook can easily release a “distributed key-value data store” as an open source project because they don’t sell a product called “Enterprise Key-Value Data Store.” This answers the question about risk, but doesn’t answer how they benefit from contributing code to the open source ecosystem. Let’s explore the possible reasons one by one. You’ll find that many of the motivations for open source vendors are the same, but with some differences.
Recruitment
Recruitment may be the easiest way to sell an open source program office to upper management. Show them the costs associated with recruitment and the return on investment, then explain how to develop relationships with talented engineers to connect with talented developers who are interested in these projects and happy to work on them. I don’t need to say more, you understand!
Technical Influence
There was a time when companies not specifically engaged in software sales found it difficult to directly influence their software vendors’ development cycles, especially when they weren’t a large customer. Open source has completely changed this, putting users and vendors on a more level playing field. With the rise of open source development, anyone, if they’re willing to invest time and resources, can push technology in a chosen direction. But these companies have found that while investing in development yields fruitful results, overall strategic efforts are more effective—compare bug fixes with software construction—most companies push bug fixes upstream to open source projects, but some companies are beginning to realize that coordinating sustained work through deeper commitment and faster feature development is more beneficial to business. Through the open source program office model, company staff can accurately sniff out strategic priorities from the open source community and then invest development resources.
For rapidly growing companies like Google and Facebook, the leadership they provide to existing open source projects is still insufficient to meet business expansion. Facing the challenges of intense growth and building ultra-large-scale systems, many large enterprises have begun building highly customized software stacks for internal use only. Unless they can convince others to collaborate on some infrastructure projects. Therefore, while they maintain investments in areas like the Linux kernel, Apache, and other existing projects, they’ve also started launching their own large-scale projects. Facebook released Cassandra, Twitter created Mesos, and even Google created the Kubernetes project. These projects have become major platforms for industry innovation, confirming that this initiative is a compelling success for the relevant companies. (Note that Facebook stopped using Cassandra internally after it needed to create a new software project to solve larger-scale problems, but by then Cassandra had become popular, and DataStax took over development.) All these projects have accelerated the growth and development of an entire ecosystem of developers, related projects, and end users.
An open source program office that isn’t aligned with company strategic initiatives cannot succeed. Without this, these companies would still try to solve these problems individually, and more slowly. Not only do owning these projects help solve internal business problems, they also help these companies gradually become industry giants. Of course, Google has been an industry giant for many years, but the development of Kubernetes ensured software quality and gave it direct say in the future direction of container technology, far beyond what it had before. These companies are still known for their ultra-large-scale infrastructure and being Silicon Valley mainstays. Less well known, but more importantly, is their intimacy with technical production personnel. Open source program offices lead these efforts through technical advice and relationships with influential developers, combined with deep expertise in community governance and personnel management, to maximize their influence.
Marketing Capability
Parallel to technical influence is every company talking about their efforts in open source. By spreading messages related to projects and communities, an open source program office can provide maximum impact through targeted marketing campaigns. Marketing has always been a dirty word in the open source world because everyone has had bad experiences caused by corporate marketing. In the open source community, marketing takes a very different form from traditional methods, focusing more on what our community has done in strategic directions. Therefore, an open source program office won’t promote projects that haven’t released any code, but they will discuss what software they’re creating and what other initiatives they’re participating in. Basically, there won’t be “vaporware.”
Think about the first work Google’s open source program office did. They didn’t just simply contribute code to the Linux kernel or other projects, they talked about it more and often gave keynote speeches at open source conferences. They didn’t just give money to students writing open source code, they created a global program—”Google Summer of Code,” which has now become a cultural touchstone for open source development. These marketing efforts established Google’s position as an open source giant before Kubernetes was even developed. Ultimately, Google had significant influence during the creation of the GPLv3 license agreement, and the company’s spokespersons and open source program office representatives became major figures at tech events. The open source program office is the best entity to coordinate these efforts and can provide real value to the parent company.
Improving Internal Processes
Improving internal processes doesn’t sound like a big benefit, but overcoming chaotic internal processes is a challenge for every open source program office, whether for software vendors or departments within companies. While software vendors must ensure their processes don’t overlap with their released products (for example, accidentally open sourcing their commercial software), users are more concerned about infringing intellectual property (IP) laws: patents, copyrights, and trademarks. No one wants to be sued just for releasing software. Without an active open source program office to manage and coordinate these licensing and other legal issues, large companies face huge difficulties in open source processes and governance. Why is this important? If different teams release software under incompatible licenses, this is not only embarrassingly problematic, it will also create huge obstacles to achieving the most basic goal of improved collaboration.
Considering that many such companies are still growing rapidly, if basic process rules cannot be established, resistance can be expected. I’ve seen a huge spreadsheet listing approved and unapproved licenses, and guidance on how (or how not) to create open source communities while complying with legal restrictions. The key is to have something to rely on when developers need to make decisions, and every time a developer wants to contribute code to an open source community, without generating massive legal overhead and inefficient IP checks.
Having an active open source program office responsible for maintaining licensing rules and source contributions, and establishing training programs for engineers, helps avoid potential legal pitfalls and expensive lawsuits. After all, good open source collaboration can reduce incidents where the company loses money because someone didn’t read the license. The good news is that companies can worry less about proprietary IP conflicting with software vendors. The bad news is that their legal issues aren’t complex enough, especially when they need to directly face resistance from software vendors.
How does your organization benefit from having an open source program office? Share with us in the comments.
The author of this article, John Mark Walker, is Director of Product Management at Dell EMC, managing the ViPR Controller product and the CoprHD open source community. He has led many open source communities including ManageIQ.
Compiled from: https://opensource.com/business/16/9/4-big-ways-companies-benefit-having-open-source-program-officesAuthor: John Mark Walker
Original: LCTT https://linux.cn/article-7950-1.htmlTranslator: Chao-zhi Liu
Reposted from: Developer Relations »
