Onymos pitches a novel approach to cutting into 70% maintenance costs - and pokes open source in the eye in the process

If I was from the North of England I would probably start with a line such as, `When I were a lad, they used to say…’ Well, I’m not from the North of England, but the sentiment is quite appropriate, because I feel I have heard the key line from a survey sponsored by US start-up Onymos since my earliest days of writing about computers. 

This is the line that goes, ‘Applications developers spend at least 70% of their working life and overall budget on maintaining existing applications when they should be writing all the new applications their employers and users really need’. That figure of 70% has stayed true and constant for all those years, disregarding totally every attempt the software industry has so far made to reduce it. 

All the signs suggest it may indeed be an immutable ‘law’ of software, at least until something really significant happens to drastically reduce the number of applications produced, or changes the way software itself is written, or at least managed. For example, though modern applications make maintaining them easier and faster, there are now so many more of them to maintain that the 70% spend is also maintained.

Onymos is the latest company to pitch itself at making a significant dent in this workload and prove this ‘law’ to be mythical. The company published a survey that showed that 28% of respondents complained that new applications development was taking six months or more, and that only an additional two percent were getting working results in four months or less. 

Implicated in causing this delay was the accumulated workload of updates for existing applications, with 56% of respondents stating that this was increasing year-on-year. Even more, 70%, stated they were dissatisfied with the time allowed for new applications innovation work.

License the source code - open, but not open source

However, Shiva Nathan, the founder and CEO of Onymos, is confident his business has come up with a new approach to short-circuiting the issue with a low code/no code model that should, he suggests, also reduce systemic bugs and security risks that can come with the code module approach and open source code in particular. 

He is calling this Pro-Code, which unsurprisingly stands for Professional Code. Though he doesn’t uses such words, there is the implication that Onymos aims to treat developers at its customers as adults capable making their own development decisions within the scope of the range of code modules it has developed.  

He likens this to being the next iteration on from the operating system and its ability to bring applications and tools together in a system. From the earliest days of computing, this has now developed into the ability to link and integrate applications APIs, he argues: 

We provide end-to-end features, so when you're building an application and you want payment, you don't have to go read all Stripe’s APIs and PayPal’s APIs to build your payment module, nor read AWS, Azure or GCP APIs to take the payment objects and store them in some database because you want to keep the transactions stored somewhere. We provide the end-to-end feeds, we call them features. That's what we do. So application developers just buy our features, put together all the basic things that they need - login, chat. notification of payment, ARB or whatever they need - and they are only focusing on business logic.”

Nathan compares it to working with a tool like Visual Basic, with the same conceptual model to provide and link the business logic connections. The goal is to provide an environment where that it is all the developer has to think about. The Onymos platform takes care of technology issues, such as the operating system upgrade of an end user device: 

What we have done is we license the actual source code or professional code to our customers. They actually get the real source code that they can now check in to the source control system, run their vulnerability and penetration testing, have the developers look through the code to make sure that there's no malware or anything running, and it gives professional code. With low code or no code you don't even know what's going on under the covers.” 

Open Source as security risk

This raises an obvious question - could this not have been achieved just as easily using open source code? The answer is not as expected. Nathan acknowledges that the company could have gone the open source route, but points out that this would leave enterprise users facing a problem with the application that they then developed: 

The problem with open source for enterprises is that we have state and non-state actors looking through every line of open source code to find out the vulnerabilities, so that they can leverage those vulnerabilities.

He suggests that any enterprise in the healthcare or finance space would shy away from open source because of that possibility of discovering vulnerabilities that can be easily exploited. The other factor that concerns him is that, as open source, Onymos doesn’t make revenue from it. 

A second factor for enterprises to be concerned about is that open source projects can be shut down anytime, because there's no contractual obligation to maintain and support any open source application. 

I did observe at this point that GitHub, back in 2019 launched a sponsorship scheme whereby individuals or organizations could take responsibility for such ‘orphans’. This was seen as important as many such orphans are still component parts of larger applications out in the commercial world, and can be seen as security risks because they are unsupported. They can also be expensive to sort out. For example, several of these lay at the heart of the Huawei vs Western state interests at the time of the launch of 5G mobile comms. Huawei invested $2 billion in a software laboratory so they could be identified deep in its code.  

Nathan’s response was, well, interesting:  

My two pence on that: GitHub actually had the right idea and right benevolence behind that. But the unfortunate problem is there are not as many adopters as adoptees. The problem is like the same thing with children - it’s a really good thing for someone to say,  ‘There are so many orphan children, let's adopt them’, but are there as many parents who have the wherewithal to adopt them?

“Think about Google, for example. Google promotes so much of its software as free software. But Google kills much of the software with no obligation. There is actually a graveyard for Google projects.”

(Looking here, Google Graveyard - Killed by Google, one can see that the total at the time of writing is 293. GitHub has been asked for more information on the Sponsorship Project, but at the time of writing no answer has yet been received).

How to cut the 70%

In Nathan’s view, licensing the source code gives users the best of all worlds, not least being a contractual obligation to support the modules and platform for a stated number of years. The licence subscription then covers all updates, and users are able to choose which updates they take. This allows those with applications that not only need no changes, but also those for whom any unnecessary or ratified change could be a breach of regulations or governance requirements, to maintain their status quo for that application while making changes elsewhere across their applications portfolio.

In practice, however, his experience says that, given how rapidly software is evolving, the licensed source code that Onymos delivers to a customer is almost useless in 18-to-24 months. If nothing else, this is because third party code changes so much in that time. When APIs change, everything can change in the ecosystem. Having a subscription licence means customers will, at least every year, get delivered the latest API changes, taken care of in the platform.

This then covers the full set of code modules Onymos provides, which in turn cover the vast majority of maintenance and routine updating tasks that most applications will require, including email address and password changes, access management, contacts management, biometric tools, chat services, document ID, as well as many others geared to the needs of particular horizontal applications, such as IoT, and specific markets, such as healthcare and education. The source code is 100% customizable, says Nathan: 

The way that I explain to CTOs is this - imagine your team slept tonight, woke up tomorrow morning, and magically has all the source code checked into your source control system and getting constantly updated, and when the APIs of all these cloud and service providers are getting changed, your engineers are focusing only on what's important for your business.