> Wallaroo is an open source project.
> You can run all Wallaroo code in a production environment for free on up to 3 server or 24 cpus.
So it is not an open source project then.
> You can run all Wallaroo code in a production environment for free on up to 3 server or 24 cpus.
So it is not an open source project then.
The enterprise code requires a commercial license from us once you are using more than 3 servers or 24 cpus.
All of the code is available and can be modified and redistributed under the same license.
This is effectively the open-core model except we are making the code for the "non open-core" portion of the code base available as well.
We are granting more access and rights to the user than is standard with the open-core model.
We started with "low" numbers because we aren't sure what the right cut off will be and we would rather give people more in the future then realize we gave them too much.
If we decide that 5 servers/40 cpus is the right level then everyone who gets an increase will be happy. If we started at 5/40 and realized that the vast majority of use cases were fine at that level and wanted to lower that number, we'd be screwed and would ruin trust. So, we started with what we thought was a nice low minimum and as we go forward, we'll potentially raise the limits.
It was at least partially informed by a POC we did for one of the major US banks were we met their targets with 5 server and 30 cpus. It was the sort of application that we think is reasonable for us to get paid for (so we can keep building Wallaroo) so that also acted as an upperbound for our early discussions.
In the end, we want people to be able to use Wallaroo and get value out of it. And we want to be able to build a business and keep building this thing that we love. And as I said, we want to be cautious and make sure we are always in the position to give away more rather than having to take things away.
There are features that might eventually become 100% free and open source as we move forward. What we want to avoid is ever having to close the source on a feature.
I hope that answers your question. Sorry, its been a long few weeks polishing up the first release and it's been a very long day today so I'm a little tired and rambly.
In an open-core model like Nginx there's an open-source edition and there's a commercial edition and there's clear documentation on what features are available on which version. There doesn't seem to be anything similar for Wallaroo.
At the moment, core stream processing and state management are 100% free.
The forthcoming exactly-once and autoscaling features (they mostly exist, just not general release yet) are enterprise features.
There are build time options to decide what features get compiled in.
I hope that helps a little. We will be improving the information around that over the coming weeks. There are some issues around how installation etc should work, what are the defaults and we punted on those. Our assumption for punting on those is that it's unlikely anyone is going to want to put Wallaroo into production during the next month or so and that if they do, they could contact us to get more information.
It's not the best answer but we decided to invest time in other bits of polish while we figure that out.
> Wallaroo is an open source project. All of the source code is available to you. However, not all of the Wallaroo source code is available under an "open source" license.
Hence, I would say that the meaning really isn't clear, especially not in the context where it's stated. This lack of clarity is further bolstered by the blog post linked from the project webpage where they mention it's going to become open source, there they spend a fair amount talking about exactly once delivery and how important it is. It turns out that exactly once is not a feature covered by the Apache license.
Almost every project containing both for-payment parts and open source parts split them into separate repositories, it's a good practice when there are different legal agreements involved, and I see no real reason for not splitting it up, except possibly that pony might be one of the opinionated languages where you can't build things if not everything is in the same folder?
If that is the case, those constraints are - as in go - rather shortsighted. The world is a complicated place, simple solutions rarely work as well as one might hope.
Glad to see Pony adoption, disappointed in this "open source" project. Free Software or nothing, please.