In software engineering (SE), finding the right Intellectual Property (IP) management for a development is often a hassle. The debate is circling around these lines:
Well, these things are obviously private to the customer!
Yes, but these other things should belong to the developer community!
Look, this is so generic and non-critical, it should be open-source!
As all sides are right, the discussion often ends up with a frustrating compromise… unless you consider multiple IPs!
What is a layered-IP strategy?
In this approach, the idea is simply to split your development along the lines of IPs. A private feature will go into a private repository, a more open one will go to a more visible repository.
- Wait, what? The IP will shape the development? This is awkward! Development should be driven by the technical needs. Do not put lawyers in this for god’s sake! -.
There is a solid reason for this. The “Conway’s law “ states the following:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. - Melvin E. Conway
In our present case, we have several organizations trying to work together. It is therefore logical to split the development between the softwares that reflects these organizations interactions.
Do you have an example of a layered IP ?
To illustrate the approach, we will use the layered IP of a collaboration between Cerfacs and the aerospace motorist Safran group. We, at Cerfacs, provide to several design departments a set of tools and graphical user interfaces. These developments are typically mixing confidential features, academic ad diffusion limited HPC tools, and open-source core tools.
We developed a set of various interconnected softwares, as shown in the following image:
You can see three layers:
- The upper part, in yellow- is a cluster of open-source very small projects, around 3K lines each. They gather all the parts showing no confidentiality issues, either for the Cerfacs or the Safran Group.
- The middle level, in green, include mid-sized projects (<10 Klines) shared but limited to the community -Cerfacs and shareholders, including Safran Group-.
- The lower level, in blue, is about private projects of variable sizes. These are the exclusive property of Safran group.
When the developers work in this frame, even the youngest one are forced to discuss of the confidentiality and/or the generality of each feature. Two flows are encouraged : generic elements are moved “up”, to the open-source layer with a high visibility ;confidential elements move “down” in the private layer.
How is layered-IP good for a project ?
The layered IP brings you the following advantages:
- First of all, there are “private developments” with full property given to the customer. As these are focused on confidential features, the mapping of what is specifically developed for the customer is very clear.
- The fact that developers must talk about the confidentiality enforce the confidentiality awareness of all contributors. Confidential ideas are much safer this way.
- As many developments go to high-visibility open-source packages, contributors have a very strong incentive to create high quality products. This enable a soft power pushing to high quality software.
- Small separated softwares imply short learning curves, making the overall project extremely reactive.
- As many parts are available to others customers, other projects will re-use the same bricks, ensuring an external flow of funding and manpower, even if the collaboration is stopped. This reduces a lot the future uncertainty, and increases the return over investment.
What are the downsides of layered-IP ?
This layered-IP strategy imply several downsides,
- All softwares must work together, even if their progression is not in sync. This is enforced using the semantic versioning (semver.). The danger lies in potential regressions when one of the software is upgraded. You can read more on tackling non-regression issues with semver..
- The installation procedure involves several sources, which harder to complete than a single-source installation. This challenge is however common and largely documented. For higher level languages, standard procedures exists (virtual environments, conda distributions). The code can also be containerized on mainstream resources(docker) as well as HPC resources (Singularity)
Takeaway
The layered IP strategy is, according to our experience, a good solution for complex IP projects. The inner working is exactly the same as any commercial software - which are always based on lower level open products-, except that the developments are no more limited to a single final layer.
At a glance. Layered IP project include several separate developments, where single IP focuses on the single final product. The community -consortium, company with shareholders, any group- is bound to build reusable elements.