Having your project used by an enterprise is a milestone for many. But a great number of projects make that feat close to impossible when not having a support system in place. Available support is often an absolute requirement for those within the largest user categories. Sizeable organizations tend to have strict and rigid systems for assessing relevant alternatives. If you don't check off for support, you risk being left out of consideration despite having a great solution.

In another article, we wrote about why many large organizations prefer Red Hat over Ubuntu, and how support seems to be playing a crucial role in their preferences: Despite very varied support experiences, many choose Red Hat over Ubuntu due to the comfort of having a solution that checks all the boxes; integrations, security, lifecycle maintenance, and support. We could easily have added the word “requirement” with “comfort”, as those considerations often go hand in hand. 

For many, the process of being adopted by a large company is somewhat of a black box. So what does the process actually look like, if you want to attract enterprise-level users?

Who makes the call?

A good place to start may be to understand who actually makes the call of using a certain software. It depends on size, but the largest companies may have a dedicated Open Source Program Office (OSPO), working closely with both the CTO, CIO and legal department. Smaller enterprises may find it sufficient to have an Open Source Manager (OSM). Due to the increased importance of open source in the last decade, this role has actually turned into more of a dedicated and high-level role and not just an area of responsibility. From a given spec, the OSM may come with recommendations on which open source projects to work with, while the final decision is a collective assessment together with of course the CTO, the legal department, and other senior developers that may end up working closely with the code. 

Factors enterprises consider - and support’s place in this landscape

For larger companies, picking a project to work with, of course goes beyond pure code. It requires due diligence and evaluation of a range of factors. How extensive this due diligence is and how it is carried out, do of course vary quite a lot, but most larger companies do consider many of the same factors. 

Usually they will start out by looking into what one could coin as non-negotiable criteria. These are of course whether the code is a technical and functional fit. Does the project provide the features and capabilities needed? Here one will look into core functionality, performance and scalability, architecture, code quality, and compatibility, to mention a few technical headlines. If this checks of the boxes, one will further naturally go on to consider the legal and compliance elements, including factors such as license type and dependency scanning. Legal evaluations have become increasingly important throughout the last few years. The last must-have criteria is security. This means looking into how a project is handling security vulnerabilities, how they are patching them if they occur, whether code has been independently audited by a third-party, and if they can provide a Software Bill of Materials (SBOM), which many large companies would really like to see. 

If you can pass the technology fit, legal and compliance, and security assessments, next up will be what could be regarded as more high-priority categories rather than must-haves. For some enterprises these categories may also be more like must-haves. These considerations include looking at community and governance, considering aspects such as community size and activity, project governance, and support options. Further they will consider documentation and usability, looking at the quality and how extensive the documentation is, and how easy the project is to get started with. Lastly economic factors will be assessed, including cost savings, development and maintenance costs, and the cost of exiting the solution (“vendor lock-in”) if it does not work out as anticipated.

How important is support? 

Most larger companies require at least one of two: Either you should have great documentation or great support. Ideally both. Having great documentation is something that takes time, and for many, not the “cheapest” way to satisfy enterprise needs at an early stage, especially if the code is changing frequently. There are of course several elements to consider here, such as how much the OS code differ from the majority of the code the team works on from day to day, how critical the code is in their software, whether it is a part of one or several features, and if acceptable downtime for that feature is one minute or one day. We have written more about this in “Do I need a support system with an open source Solo Project”. Despite the title, several of the elements there apply to both solo projects and foundation-level projects. 

Regardless, at a general level, knowing that if something breaks, having a clear and reliable way to a solution, is critical for all enterprise-level companies. This means looking at whether the project is able to offer Service Level Agreements, including guaranteed response times for bug fixes and security patches. As well as having the right expertise available, meaning developers who deeply understand the code, ideally at short notice. This can be delivered by either a company offering a commercial version of the software or professional support services, or simply the core team themselves. 

Despite checking off for commercial support, the strength, activity and availability of the community is also a major consideration. Here one may look at how quickly questions are answered. How easy is it to reach out and ask for help in the community? How quickly are questions, bugs and feature requests reviewed and addressed? They are also likely to consider their internal capacity to support an open source project. In addition to several internal considerations regarding capacity and technical skills, they may also look at how easy it is to reach out for guidance, training and support to build up the capacity and competence.

PhoneGap - killed by lack of documentation and support

Personally I liked PhoneGap when it launched. It had several good features, and the appealing promise of making mobile development faster and easier. It seemed to be a good opportunity for web developers to jump on mobile development, in the same way as with for example Cordova. However, in 2020 Adobe officially discontinued support and development for PhoneGap, and the project quite quickly “died out”. Why developers abandoned the code may be up for discussion, but from my perspective the frequent breaking changes combined with chronically limited or outdated documentation and support throughout the project’s lifetime, topped with Adobe pulling the plug, seemed like the lethal blows that brought the project down. The circumstances made it difficult for developers to jump onboard, especially for web developers that were not familiar with the intricacies of mobile development as the framework itself or its plugins were frequently breaking and naturally left web developers frustrated and stuck.

A simple, but important final note

Support is not equally important for all projects, but as a rule of thumb; If you have limited documentation, you need to have strong support, and vice versa. Otherwise your user base is likely going to abandon your project if they run into multiple issues over time. The best is of course both, as well as a strong community. That said, SLAs and paid support should only complement, not substitute, the helpful spirit of open source communities. So, from our perspective, documentation, strong communities and structured support, together, creates the most powerful mix, especially if you are aiming for enterprise users.