Monetize Open Source Software with XS:CODE
Written by Nikos Vaggalis   
Monday, 22 June 2020

Introducing XS:CODE, a subscription based service looking to get OSS developers paid for their work.

Even as a hobby, writing OSS is serious work, up to par or even superseding that of closed source software, since hundreds or even thousand of eyes will be looking at your source and judging you. Hence you should be on your top performance.

On top of that, you have treat it as a real world project which has to be launched, managed, maintained and contributed to. Some of the tasks involved in that, as we've explored in "The Open Source Guides To Managing Open Source Software Projects", are to:

  • Write code or documentation
  • Choose a license
  • Write a README
  • Write your contributing guidelines
  • Establish a code of conduct
  • Name and brand your project 
  • Write promo material

Let's not forget the people management aspect too, as well as finding users/clients for your project you also need contributors and ideally a community. Not only does this mean taking care of the project's usability and help others out by reviewing their code or offering them advice, also requires:

  • Figure out your message:"you should be able to explain what it does, and why it matters"
  • Creating a website for your project to make your project friendlier and easier to navigate as well as drive people to find it and remember it by a single namespace.
  • Building a reputation 

While OSS projects are run by people volunteering their time pro-bono, there are instances that some amount of money could be most welcome, such as when: 

  • Getting paid to contribute to open source is the only way some people can participate, either because the project requires it, or for personal reasons.
  • Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
  • Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other care taking obligations. 

xscode-logo

This is where a new startup, XS:CODE, steps in, helping to monetize OSS projects.The notion is simple - continue writing open source code for the community but charge companies, not for using it, but for providing extra services. So enterprise users would pay to: 

  • Get priority bug fixing, support, consulting or even code customization.
  • Access extended versions of open source components. Get extra features, better performance, and more frequent updates.
  • Alternative licensing in situation where the license of the project gets in your client's way by introducing a multi-licensing scheme. 

xscode-1

XS:Code acts as the middleman taking care of the little details so you just focus on what you do best - writing code. When making a sale, you keep 75% of the revenue.

From that list what I find most important is the frequent updates and priority bug fixing. Since open source is so prevailing and ubiquitous, it has found its way into commercial applications that utilize not just one but a myriad of open source libraries. Many of those don't get updated, are not maintained or simply get abandoned because the maintainer had no time, had family or life constraints or tried to find something more profitable to make a living.

Add to this mix the vulnerabilities that remain unpatched because of the library not getting updated, and you have a volatile cocktail that is more potentially disruptive for companies that use those libraries in their commercial products or infrastructure, for example in a DBMS setting. In fact MariaDB, MySQL and others offer their code for free, but charge for this kind of support.

With regard to the prevalence of bugs that need fixing, Veracode's Stateof Software Security: Open Source Edition, which analyzed 51,000 unique open source libraries across 85,000 applications, concludes:

We are presented with a startling fact — most (71 percent) applications have a flaw in an open source library when they are first scanned.

and

It’s true that the more libraries a given application includes, the more flaws a developer is going to introduce on average.

The report also brings forward the transitive dependency issue in that the core library itself might not have an obvious vulnerability, but instead carries a transitive one if it has a dependency on an other third party library which is vulnerable itself.

So we have established how important is for OSS libraries or applications to get patched and updated and that's not just the core and most popular libraries. As such I pose two questions to XS:CODE. How do you handle those transitive dependencies when the developer of a core library is paid to do a priority patching, but there's also a lesser know third party dependency that should be patched too?

And then, for the core libraries like Java's slf4j-api or jackson-annotations, Javascripts's lodash or .NET's newtonsoft.json the monetization scheme of adding proprietary features etc might be plausible, but what about the lesser known or niche ones? If supply and demand is the principle here, then there's no chance for them to make any money.

There's also another way of both strengthening and making money out of OSS which we examined in "Software Security is a Civil Right!" where we discussed the EU initiative kickstarted by the EU Pirate Party because it thought that enough is enough after severe vulnerabilities were discovered in key infrastructure components like OpenSSL.

It is amazing to think that the OpenSSL Software Foundation which is responsible for the maintenance of the OpenSSL library, the cornerstone of safe transactions on the Internet used by millions of websites and organizations, receives just $2000 of donation money per year and has only ONE full-time employee working on the library.

All that was revealed after the discovery of the Heartbleed bug, something that finally shook the waters and motivated the big industry names to support the foundation with proper funding.

As such to serve the wider good, a state-funded bug bounty for mission-critical OSS application audits was kickstarted.

On that line, I think that XS:CODE should also ensure that bug fixes and vulnerability patching, once done for the paying customer, also propagate to the (free) community in due time so that everybody benefits, keeping the OSS spirit and values alive too and not just commodify them.

In conclusion, I hope XS:CODE's initiative is going to bring stability to both OSS developers' and their projects' lives.

 xscode-logo

More Information

XS:CODE

Related Articles

EU Bug Bounty - Software Security as a Civil Right
The Open Source Guides To Managing Open Source Software Projects

 

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Banner


Android 15 Developer Preview Updated
25/03/2024

Google has released Android 15 Developer Preview 2 with changes including better handling of automatic language switching and updates for OpenJDK 17.



Apache Shiro 2.0 Released
21/03/2024

Apache Shiro 2.0 has been released. The Java security framework now requires at least Java 11, and has added support for Jakarta EE 10.


More News

raspberry pi books

 

Comments




or email your comment to: comments@i-programmer.info

Last Updated ( Monday, 22 June 2020 )