Why we choose commercial licensing over FOSS

Iain Cambridge on July 25, 2021

In software development, free open-source software (FOSS) has always been important and without FOSS, IT would not be the same as it is today. It is hard to think of a company in this world today that isn’t relying on FOSS for part of its tech stack. For many developers, FOSS is a major part of being a developer and they feel like contributing to FOSS is something they, as a good developers, must do. Some loath the idea of commercial software. So it’s with this in mind, we feel like we should explain why we choose not to use the FOSS model. Instead, we have gone for commercial licensing. ANd we

We want to provide a professional level of support

FOSS is great but it is commonly worked on by volunteers who have day jobs working on other things, even those who are being sponsored by a company to work on the project are so overwhelmed with the amount of work they are unable to provide the same level of support you can get from a company selling software. Support is a hard job, support is also a job that requires skills that many people do not have. So even though the volunteers who work hard on FOSS want to provide the best support possible, they are limited by time, resources, and sometimes skillset. With the money, we make from selling Parthenon we can invest in ensuring that users get a good level of support. We can invest in ensuring that critical bugs are fixed in a timely manner. There are many FOSS projects that are amazing but they have small bugs in them with remaining unfixed for a large amount of time because the sole maintainer of the project is busy with the important things such as spending time with their loved ones and the FOSS project is a side project that they may only invest a few hours of time in per month. With commercial software, we can ensure developers have time to fix issues and still have free time to enjoy their lives.

We want to provide high-quality documentation

The importance of documentation for a software library can not be overstated. If you ask any FOSS project what they would like help with the most, we believe that the majority of them would say with their documentation. The thing with documentation is, it’s not sexy, it’s not the most enjoyable task, etc. However, it is probably the most important task. When you see a problem with the documentation with a FOSS project, normally the only real answer you have is to fix the problem yourself, if you’re able to. You may not have the technical expertise or time to figure out what the problem with the documentation is. There is the option of creating a bug report but there are no promises on if and when that can get fixed. 

We want to provide flexibility

After over a decade in IT building things on top of FOSS, I’ve experienced one thing quite a few times that you can never expect from FOSS and that is to be designed for change. Athena was born out of the experience of working with Sonata Admin which is an extremely good admin framework. The company I was working for built their back-office system heavily on Sonata and we ran into several issues when it came to growing as a company and a tech department. One of the core issues as it is only designed to support SQL databases and Document databases using a specific set of libraries. We moved some data to a microservice that we only had access to via HTTP. We spent a week looking into modifying Sonata in a way that would allow us to continue to use it. We decided after a week, there was a way but it would take us less time to just build a separate admin system for this data. This is in no way a fault of Sonata. Our use case is not a supported use case. 

Another issue we had was with scaling and having Sonata deal with large amounts of data. Again this is not something Sonata is designed to do and the libraries they use are also not designed to do what we were doing. Again, we ran into an issue that the FOSS we are using was not designed to do and was not part of their mission.

I wanted there to be an admin system that could do these things and I wanted it to be in the mission statement that is the purpose and provide guarantees. Commercial licensing allows this.

What we can provide because of commercial licensing

One of the core things with Parthenon that we wanted to provide was SLAs. We really want every company building software to have SLAs on the software. And we honestly think commercial licensing is the only way to achieve it.

The following guaranteed bug response times:

  • Critical – 24 hour response time
  • Major – 7 day response time
  • Minor – 30 day response time

The following guaranteed performance response time:

  • 30 day response time

The following guaranteed documentation response time:

  • 30 day response time

Check out the pre-order offer at


Get the advantage by keeping up to date on how tech can help your business and learn technical things in a non-techincal way by subscribing to our weekly newsletter.