How startups can leverage platforms while protecting IP and avoiding lock-in //09.09.20
Startups tend to have small engineering teams that need to maximise their productivity. They need to focus on quickly releasing new features that are driven by customer demand, but they don’t want to be distracted by building and supporting capabilities outside their core competency or product mission. This is where it can make sense for a startup to consider leveraging a platform – a complete environment that enables the creation, deployment and management of applications to optimise efficiency, minimise costs and get compelling features to market faster.
One of the most critical considerations a startup needs to make in the context of this decision is how to appropriately protect their intellectual property. There are important ramifications when deciding whether or not to use a platform within a product. Should a startup use an open source technology, or consider proprietary solutions? Each entails a different set of risks and rewards that need to be weighed against a company’s priorities and longer-term goals.
The open source approach
One common approach to protecting IP and avoiding becoming locked into a proprietary vendor’s technology is to leverage open source. Using an open source platform within your product typically has no software license cost and can speed up development, in addition to providing valuable transparency that you don’t get from proprietary software.
That said, you must understand open source licenses as they can vary widely in terms of the types of usage permitted. There can be limits on redistribution rights that can impact a company’s strategy if not carefully considered. Open source code might even be co-mingled with proprietary code within some projects. In some circumstances, embedding in your product can inadvertently convert your proprietary code into open source software, forfeiting your IP protection and making your confidential code publicly accessible.
In addition, using open source can be more risky than proprietary software when it comes to the potential violation of third-party IP. It can be argued that developers can contribute infringing code to open source projects more easily since they don’t have the same commercial controls as proprietary software. This can expose a startup to the resulting liability as there are typically limited protections for licensees.
Lastly and probably most importantly, any security vulnerability in the open source platform will directly impact your products. You might find yourself spending time and effort plugging security holes in your product instead of focusing on new features.
Proprietary technology
Sourcing a platform from a proprietary vendor can have advantages, such as higher performance, security, enhanced legal protections and a more integrated development environment. On the other hand, it doesn’t have the transparency of open source. This can make it harder for a startup to justify to its board why embedding it in a product doesn’t introduce a risky dependency.
Software architects focus a lot of effort on reducing lock-in risk by building options into applications, but it should be clear that there is a cost associated with both avoiding lock-in and being locked in, which needs to be balanced. Building an abstraction layer or modular architecture that allows you to swap proprietary platforms in and out can be an effective approach that should be explored, but over-engineering a solution to account for every scenario is not practical or cost-effective. Trade-offs should be considered in-depth as they can have downstream consequences such as unforeseen impacts on compute or storage infrastructure, for example.
Betting on the benefits of a proprietary platform can make sense – even if there are high switching costs – when the feature or functionality gain represents a significant incremental monetisation opportunity. This is particularly true when the capabilities are outside your startup’s core domain.
Conversely, if exploiting those benefits requires you to use their entire stack in a way that compromises your freedom to build options into your product, it might make sense to think twice.
Weighing the benefits and downsides
Taking advantage of open source or proprietary platforms within your product can have major advantages in the form of cost savings, faster time to market and more compelling capabilities over building features and functionality in-house. This is particularly true when what you want from the platform is outside the scope of your company’s core product mission.
If you do explore an open source platform, make sure you develop an in-depth understanding of the license model and can accommodate the potential higher risks of infringement of third-party IP, limited warranty protections and other legal considerations as compared to proprietary software.
You should also understand the license constraints in the context of your company strategy. Evaluate whether or not the open source technology truly qualifies as a platform. Does it have a fragmented development environment or infrastructure requirements that will introduce high costs, or limit your ability to scale?
When considering a proprietary platform, it makes sense to invest in understanding if your product can be architected to facilitate adaptability that will minimise the cost of switching. Can your solution that embeds the platform be offered as a modular add-on, separate from your core product, to reduce unnecessary dependency? Proprietary platforms can offer greater performance, security, and functionality than open source alternatives, but it’s important that what you choose embraces open standards.
Lastly, make sure that your legal agreement with a proprietary platform vendor gives you the protections, costs, and flexibility that justifies some level of lock-in.
Based in San Francisco, California, Garen Ingleby is responsible for Splunk’s global OEM embedded licensing business. He has been focused on intellectual property licensing for 20 years while at technology companies, including Adobe and Dolby Laboratories.
For more information, please visit: https://www.splunk.com/en_us/partners/become-a-partner/embedded.html or contact OEM@splunk.com.
