Low-code app development is very popular now, but you need to ensure the commercial benefits of your titanic new app do not founder on the low-code intellectual property rights iceberg
Low-code and No-code is very popular with a range of promises around rapid development of engaging apps with little effort and the “democratization” of the app development from “Big IT” into the hands of citizen developers.
Of course, low-code is not new at all, and was largely pioneered in the fourth-generation languages (4GLs) which peaked in the 1980s and 90s, with GUI (and even sometimes WYSIWYG) systems like PowerBuilder, Pro-IV, Omnis, StaffWare, and even Microsoft Access.
As it happens, for a period in the 80s I ran the team that supported PRO-IV after its acquisition by McDonnell Douglas Information Systems. Being written in C, PRO-IV was ported to more or less anything that had a C compiler. Not always a good thing as it happens, especially for the IBM AS/400, which had a toy C compiler that produced code that was incredibly slow (for the technical amongst you that was due to every function call being generated as an inter-segment CALL which is about 1000 times slower than an intra-segment CALL and so a baaaad thing to do)
As I may have mentioned before I am a big fan of GUI-based WYSIWYG visual software design, with a simple philosophy…
As most low-code designers are generally visual in nature, from a philosophical perspective they come under the “good” category. However, commercially speaking, there are some potentially significant commercial pitfalls of which you need to take account.
Before digging into that, we first need to have a look at the main components that make up an “app”. Whilst it is a rather corny cliché, the iceberg motif is quite apt here, as there is more of an app that you don’t see than you do, especially for low-code. The parts under the waves beneath “The App”, are the data and meta-data, supporting environment, execution engine and infrastructure on which it all runs, thus…
Not surprisingly there are some significant commercial attributes to all those parts, not the least who owns which parts, which raises the concern that whilst you might own some intellectual property rights (depending on your lawyers), due to the complexities of the other parts of the app construction, you may not own anything that you could actually take away as an useful asset.
Indeed there are a number of factors to thinks about when asking yourself the question – who really owns my app?
Considering those factors:
- IPR ownership. This is the obvious one that the lawyers focus on covering business trade secrets, copyright, patents and so on.
- How much of the total app IPR do you own?
- Portability. A key part of switching is taking your toys away and playing your game somewhere else for your own advantage.
- Can you extract any useful description and source code for the the app, preferably in a commonly recognised format?
- Third Party Access. This covers the scope of who can touch your app for development, support and general usage. (This is a historical trap for outsourcing IT services)
- Can third parties modify and support your app code, and other parties actually use the app?
- Licensing. This covers how the various parts that you don’t actually own are licensed to you and your associates and affiliates, and for how long that license actually lasts.
- What is the scope, time period and other attributes of the licence given?
- Run-time costs. This covers the costs associated with deploying and using your app which may include or exclude the infrastructure costs depending on the application and low-code service construction.
- What is the on-going pricing for deployment and use of the app, and what happens when you stop paying?
- Supplier Continuity. This covers the longevity of the supplier running your app and what happens if/when they go bust. In the past that was handled by a simple escrow clause, but which is becoming a much less tenable proposition in the SaaS world. In the worst case a supplier will cease to exist, their servers go offline, your app is gone, and any useful IP becomes “bona vacantia” owned by the Crown (in the UK, at least, other bad outcomes are available).
- What happens to your app in the event of supplier failure?
Putting those together, you might own the whole kit and kaboodle of your app, which is less than likely for low-code, although may still be the case for older 3GL-based apps; or in fact you really own nothing useful at all, just some scraps that instead somebody generously let’s you use in exchange for some of your hard-earned cash.
You can map out the extremes of the commercial lock-in that is created by these sort of considerations, against the handy ice-berg layers, thus…
Most low-code systems exhibit some of the features on the left hand side of the iceberg, and you can do some rough clustering of current low code systems according to that…
- SaaS Platforms with low-code extensibility. These might not be considered “low-code” by purists in the fullest sense, but often exhibit some of the technical features. These typically have the highest level of lock-in as you are wedded to the mass of application functionality and adding customization around the side. The systems is hosted by the supplier, and you generally pay for most/all the users, with some significant restrictions around the licensing and usage. The app “code” is not portable and when the supplier dies or you stop paying for access your app dies too.
- SaaS-like Low-Code systems, hosted by supplier. These provide low-code features but are locked to the the supplier’s systems and infrastructure with restrictive “take it or leave it” licensing and again you pay for most/all users who touch the app. Again the app “code” is not portable and when the supplier dies or you stop paying for access your app dies too.
- Enterprise Low-Code systems, with choice of infrastructure deployment. Whilst these are like the previous group just above, they start to open the sealed world, by giving options to deploy your app on different underlying cloud IaaS, or even on-premise. They may also use some open-source components for the deployment tools and landing zones (e.g., Docker, Kubernetes, etc.). However, the apps themselves have relatively low portability, even if they run in a more open environment. These types of systems are often targeted at Enterprise clients who have multi-cloud strategies. No surprise, they also therefore carry an “Enterprise” price tag and may still have supplier imposed time-based limitations of use, access and so on
- Code-generator Low-Code systems, deploy anywhere. The last group have the lowest level of lock-in and typically generate standard 3GL code, like Java or PHP. In their freest form, you only pay for the development tools, and the run-time is royalty-free with no application usage run-time costs. Since they generate code, the apps are relatively portable, although the generated code may not be pretty in a human sense. They also have effectively have perpetual life with no supplier imposed time limits unlike the other three categories. More locked-in versions will have run-time charges
Low-code is definitely a “good thing”, but you do need to go into it with open eyes and understand how the shiny promise of speedy development with high investment efficiency can be eroded if you don’t take the commercial realities into account,…
…and your app founders on the low-code IPR iceberg and its commercial case sinks below the waves.