What makes open source software successful

Leading an open source program effort takes equal parts intellectual property smarts, marketing savvy, desire for innovation, entrepreneurship, and ambition to spare. These efforts are often at the center of a company's core strategies—from developer relations and community marketing, to product development and cutting-edge engineering.

As such, the teams that lead these efforts should be nimble, lean, plugged into multiple departments within the company, and perhaps most importantly, aligned with the company's core strategies.

One does not need a close reading of the preceding paragraphs to know that I think highly of Google's approach. Even so, Google isn't perfect, but one thing they did right was to start with a leader who had a burning desire to see open source flourish. At this point, open source is so commonplace that everyone in tech-related roles to some degree participates in open source ecosystems. But open source believers, those who think open source methodologies are superior and should be advanced in all areas of technology?

Those people are relatively rare, and they're exactly the kind of person you want advocating your open source efforts. To maximize industry influence, engineering excellence is key. The massive code contributions from IBM, Intel, and Red Hat have played a major role in their ability both to deliver products more quickly and to increase their respective adoption rates once they've been released. IBM made an early bet on the Apache Web Server as a key component for its WebSphere product, in addition to its bet on Linux as the platform of the future at the time for xbased servers.

Its creation of the Eclipse Foundation has long been a success story that has spawned a quite large ecosystem. Intel has also clearly bet on Linux as the go-to platform for devices and its IoT strategy, having made major contributions to the Linux kernel for years, in addition to a smattering of contributions in other areas, including graphics drivers, big data Hadoop , and storage Ceph, CoprHD.

Red Hat, having bet its entire product strategy on open source software, is a major contributor to the Linux kernel, OpenStack, and many other projects. To maximize the impact of code contributions, open source programs can recommend the right ecosystems to invest in, ensure that other groups within the company are fulfilling their legal obligations and following the rules, and train other groups on how to participate in open source communities.

With strong open source program leadership, these teams can help steer the ship in the right direction, making sure that their engineering efforts align with other departments. Without strong leadership, many departments within a company may find themselves duplicating efforts, or worse, contradicting the engineering efforts made by others. With centralized efforts in this area, companies increase efficiency and maximize their open source impact, both internally and externally.

The success of open source begins and ends with the modern concept of intellectual property law, especially pertaining to trademarks and copyright. Without IP law, open source doesn't succeed.

The open source definition itself requires that a software project's copyright license meet certain criteria in order to qualify as officially "open source. The trick is finding that rare attorney who understands risk mitigation but doesn't stifle innovation.

The ones with strong legal leadership understand the value of license compliance, can clearly communicate the risks of any particular open source activity, and help educate other internal legal counsel on the role of IP law in open source software. When open sourcing your code, there's no more pretense about being the sole arbiter of features.

You're not. The code is out there, and so are all the features and functionality that it enables. This means that the things of inherent value you have are:. There are, of course, many other levels of value in the software supply chain, but often they're not as obvious. Thus, that your legal counsel be top notch is imperative. Which brings us to licensing.

Too much time is spent hand-wringing over license choice, but compliance with licensing is especially important for a company that wants to be known as an influencer in one or more areas of software development. Hence the need for the centralized open source program with the requisite legal team to ensure compliance and clear any legal roadblocks to innovation. Another area in which the open source program team is essential is product strategy.

Open source programs drive efficiency, innovation, and industry influence. These objectives are sometimes at odds, increasing the chance that, left to different departments in the same company, open source strategies also will be at odds. Open source programs ultimately should serve the company's interests, although that may not be as intuitive as it sounds. In some companies, open source efforts can directly contradict each other, giving the impression of no centralized planning, whereas other companies restrict their open source efforts to the point of rendering them completely ineffective.

A company may release project X, which is a whiz-bang newfangled project aimed at container orchestration. No matter the type of software—open source or commercial—code flaws will exist. The main difference is who is responsible for fixing the bugs; for commercial software, vendors are responsible, whereas the consumer is responsible for open source software. Change requests must be made to the company selling the software.

This includes bug fixes, features, and enhancements. Typically less user-friendly, but it can depend on the goals of the project and those maintaining it. Typically more user-friendly. As a for-profit product, adoptability and user experience are often key considerations.

Some very popular pieces of open source software e. Otherwise, users can find help through user forums and mailing lists. Dedicated support teams are in place. The level of service available depends on the service-level agreement SLA. Source code is open for review by anyone and everyone. There is a widespread theory that more eyes on the code makes it harder for bugs to survive.

However, security bugs and flaws may still exist and pose significant risk. The company distributing the software i. Because the source code is closed for review, there can be security issues. If issues are found, the software distributor is responsible for fixing them. No vendor lock-in due to the associated cost. Integration into systems may create technical dependency. In most cases, large investments are made in proprietary software. Switching to a different vendor or to an open source solution can be costly.

This will depend on the current user base, the parties maintaining the software, and the number of years in the market. Older, market-based solutions are more stable. New products have similar challenges as open source products. If a distributor discontinues an application, the customer may be out of luck. In some industries, proprietary software is more popular, especially if it has been in the market for many years.

TCO is lower and upfront due to minimal or no usage cost, and depends on the level of maintenance required. The community participating in development, review, critique, and enhancement of the software is the essence of open source.

This will depend on the level of maintenance and goals of the group, but it is typically better than closed source software. Most proprietary software goes through multiple rounds of testing. How well is that consumption tracked? The policy for using open source code is clear and developers are aware of it. The processes and tools for bringing in code are clear and developers are following it.

Which products and services are third-party code being used in? How many compliance issues are you having and how quickly are they resolved? You do you have a compliance program, right? See our legal resources from the Open Compliance Program for more on this topic. Goal 2 Increase developer productivity. Things to track include: Number of commits made to external projects identified as strategic to the organization Number of developers contributing.

Also, who are they and which projects do they contribute to? You have one, right? Do they follow the process for contributing? Do they ask you for help and are you prompt in providing it? Amount of time between software releases — is it increasing or decreasing? What are the engineering costs associated with contributing upstream vs.

Goal 3 Create and grow open source projects. But there are other considerations as well: Is there a clear policy for creating new open source projects and are developers aware of it? Is there a clear and easy process for creating new projects and are developers following it? For example, mobile or data, infrastructure-related projects, etc. Performance increases in your project and related product Time between releases Goal 4 Recruit and retain developers.

How did that awareness influence their decision to join the company? Does their experience with open source apply to the work that they are doing now? We encourage the developers to take a couple of extra steps in our direction knowing that by doing so they actually will get to their goal in the long run. We really try to set up a program to be a support service, not a speed bump. Sponsoring foundations, groups, or hackathons Goal 6 Align open source community interests with product interests.

Some metrics to track success in your advocacy include: How many contributions are coming from outside the organization? How many full-time contributors are outside your organization? How much externally contributed code is making it back into products? How many hires are coming from open source contributions? What to track.

Number of contributors and the ratio of external to internal contributions Projects start with the majority of contributions coming from internal developers and evolve to include more outside contributions as the source code is used or forked.

Number of pull requests submitted, open, and accepted and length of time they remain open When a contributor finds a bug or has a feature request that they can and have clearance to patch or write themselves, they do so and submit it as a pull request PR.

We live in ensuring we have the right outcomes. Number of issues submitted and length of time they remain open Users who do not have the time, permission, or ability to submit a pull request, but encounter problems with your code can submit their bugs and feature requests as an issue. We just give them the data and then sort of nudge them when we can, or when we have to.

You have only seconds of attention to sell what you have. For example, in case of my open source library Vocajs, I use the following one-sentence explanation:. This sentence instantly tells you what my project does: a JavaScript library that manipulates strings. The modular design allows to load the entire library, or individual functions to minimize the application builds.

The library is fully tested , well documented and long-term supported. Create an additional page solely describing the API. Examples of detailed documentation: lodash , ant. The documentation explains concisely and to the point all the usage aspects. You can easily understand how to use kebabCase function: what it does, what parameters it accepts, and the returned value. A few examples are presented as well. You can even find links to the source code and the unit test.

Humans are visual creatures. For example, I implemented a small open source Chrome extension Cliboardy. It copies posted code to clipboard from stackoverflow. A good part of managing the open source project is dealing with people: communicate with users, implement new features, fix bugs. While it might seem secondary at first, communication is a complex task.

Responding to issues and reviewing pull requests can take more time than expected. Sometimes you will deal with frustrated users, anyways find the will to communicate politely with everyone. Always try to explain politely your decisions and gratify contributor for spending his time. The goal is to attract new contributors to your project.

Some say that popular open source projects are based on a strong community of contributors. A successful open source project is built on efficient communication and active community. Share your repository on sites like reddit.