Starting from today Magic's open source GitHub repository will no longer be actively maintained. Due to recent events, we've unfortunately been forced to exclusively continuing maintenance of Magic Cloud as a close source project.
Magic Cloud has roughly 10 million downloads from NuGet, and unfortunately zero of our users have contributed to the project - Neither with code nor with monetary means. To put that number into perspective realise that 10 million downloads is 20 times as much as SupaBase. SupaBase is evaluated at 1 billion dollars.
In addition Magic Cloud has now become a real business model, with a quite substantial amount of revenue, through our AI and Low-Code hosting provider. So to avoid having leeches exploiting our work for free without contributing in any ways, it's therefor with heavy heart we announce that all future releases of Magic will be in the form of closed source distributions.
Professional license
However, the good news is that we will be selling professional licenses. These comes in two categories.
- Single Server License $5,000 per month
- Kubernetes Cluster License at $20,000 per month
A single server license allows you to install Magic Cloud on one single server. A Kubernetes Cluster License allows you to install Magic Cloud in one Kubernetes cluster. Both versions comes with support and setup help, and we provide. Docker images, extensive documentation, etc.
Both of the above plans also comes with all source code for usage within one single legal entity (one company).
If the above is too expensive, you can of course just purchase a cloudlet, which at the time of this writing has a starting cost of $300 per month.
Top comments (4)
From my own perspective, I still have exclusive copyright in my current projects. This makes it very easy to consider a change of strategy thru licensing. However, I find the GPL very helpful in repelling some out of the markets I care about, and by componentizing at the service level I can make central dependencies proprietary while providing other service components as part of distributions.
For example, in my own projects, things like the upper level Apollo web integration service could be built and delivered differently and under a different license. That is a form of what some now call the open core business model, except for me it would be what is at the edge, not really the core, that is then open, and what is abstract orchestration at the center can be more valuable potentially than what is at the edge which is often platform adaption.
The problem with that approach is most people don't care, they go like "ohhh, useful code, I don't care about its license, nobody will anyways know" ...
The ones who do care though are the gatekeepers to distributions and what they will permit to be packaged. If one's strategy includes having some things packaged and delivered as part of some distro, it is essential that those parts of what your doing will please them. Gatekeepers naturally always view themselves as the most important element in the software chain, too. I talk a little about this in my post about distro packaging...
Cool, my project doesn't fit the profile though, since it's a software development framework. It's got 10,500,000 downloads, and it generated zero revenue.