Hi there !
We used to host our sites on Netlify, but our eyes fill with glitter when we hear open source and self-hosted. So, we built Meli, which essentially is a Netlify alternative that lets you deploy static sites and frontend applications with ease, featuring per-branch deployments, web/slack/mattermost/email hooks, an API, and a way to manage organizations, teams and sites easily.
We built Meli on top of Caddy, a very powerful HTTP server (https://github.com/caddyserver/caddy). We’ve used Typescript, Node (backend), React (frontend) and MongoDB for the database.
It’s a beta, but you can install super easily with Docker Compose: https://docs.meli.sh/get-started/installation
Check us out at https://github.com/getmeli/meli !
Looking forward for your feedback :)
Makes me sad that you chose this name even though there’s already a free software project with this name.
As the amount of software produced increases, it’s no longer reasonable to expect everyone to avoid name collisions for software.
IMO this social rule should be relaxed to only avoid collisions for software with an unrelated purpose or a much longer name; there are not enough english-pronounceable four-character strings to go around, and it’s unreasonable to expect sole use.
Oh no, I’m so sorry ! I honestly didn’t think this would be a problem. To be honest, we chose “meli” because it means “ship” in Swahili. That said, I think it’ll hardly be an issue in practice as we both are in completely different fields.
Would you consider renaming it, now that you are aware of the previously existing project? It seems a bit thoughtless to have not even tried searching for “meli software” or a similar search term before naming your project, which would have showed the email client as the first hit.
If you can’t rename your project for some reason, perhaps you could publicly apologize and link to the email client?
Publicly apologize? What have they done wrong? The email client doesn’t have a perpetual monopoly on the use of the name “meli” across all software?
I don’t think registering https://github.com/getmeli was an accident given that https://github.com/meli is already taken.
Was excited about the project and then saw this. When are we going to stop abusing the name open source? If it’s not an OSI approved license, it’s not OSS in its true essence. /end-rant.
I agree that it was misleading of the original poster to mention “open source” in their post while not mentioning that Meli’s license is the Business Source License, which is not an open source license (as the license itself proclaims).
However, I don’t think “OSI-approved” is the ideal criterion for open source software. To give a counter-example, I think that the non-OSI-approved Blue Oak Model License is as much open source “in its true essence” as the OSI-approved MIT License is. For more examples of “OSI-approved” falling short as a standard, see the blog post Don’t Rely on OSI Approval, written by one of the lawyers who wrote the Blue Oak Model License.
While I agree with you that OSI-Approved isn’t a “standard” or a definitive list, however I am yet to see a legal precedent of Blue Oak Model License or similar licenses standing in courts.
I don’t think the abuse is using an unapproved license. The abuse is that the license doesn’t meet the criteria for open source distribution. Approval is useful for other reasons but not necessary to meet the definition.
I don’t think this license is bad. It certainly won’t stop me from considering usage of this tool.
But IMO they should choose a different term (“source available”? “shared source”? “will be open source 4 years from now”?) to use when promoting the project.
Calling it “Open Source” makes people believe distribution meets the OSD conditions and this says very plainly in the license text that it doesn’t:
So it’s easy to understand your disappointment after seeing it promoted as Open Source.
In your announcement you say:
In your license, you say:
It would be more honest to avoid using the term “Open Source” to promote this project.
(It looks like nice work, and I don’t think that license looks bad, but it’s not what I expected when I read your promotional paragraph here. Congratulations on shipping!)
This kind of looks like a useful thing. Kind of like Publii but primarily for developers.
Thanks for your kind words ! You’re right on, Meli basically stands as your deployment platform. Once you’ve built your static site, just upload it to Meli from your CI (or anywhere) using our CLI, and it’s instantly available at your-site.your-meli.com. You can also have preview branches like main.my-site.mymeli.com or dev.my-site.mymeli.com, so it is useful when you want to have previews. Once you’re done developing, all you have to do is point yourdomain.com to yoursite.yourmeli.sh, and you’re done :) Plus you get automatic HTTPs and can server thousands of requests per second on a cheap VPS, so it’s also very efficient thanks to Caddy :)
@gempain this looks great. Frankly I’ve been wanting to write something like this for my own personal use for years.
It’s a bit of a bummer to see this under the BSL. However, it looks like the change date to Apache 2.0 is extremely close to release date. Can you talk a bit about what you’re trying to accomplish/what the thinking is there?
Thanks for the kind words ! This is a mistake from us, the change date should be in 2023, thanks for pointing this out. The reason behind choosing a BSL is that we’d like to finance the project by running a cloud version of Meli :) Basically you can do all you want with the tool, but we find this license fair enough so that a team like us can fully dedicate its time to making this project awesome while allowing others to use it for free.
Hey, really cool project! Honestly I was looking for something exactly like this anddd youve got packaged up in docker, saves me from having to do that!
Looking forward to using it.
Also, I personally think that the license choice is appropriate but considering how this is a new type of license do you think after some time your team could share some thoughts on how successful it was?
I don’t want to detract too far, but I think finding a sweet spot between user freedom (open source) and sustainability is very important. I’d rather a BSL project that is updated and improved over the years than an open source prototype that cant reliably be used because the developers had to move on to another project.
Thank you for this really nice comment ! I think exactly the same way as you ! I am aware that the debate over BSL is hot at the moment, and not every one will agree. We want to focus solely on developing this tool, and in this context, BSL makes sense as it gives the team a chance to monetize the project fairly. Everyone can use the tool for free, with no limitations, except the one mentioned in the license. It’s a fair model, which has been supported by the OS foundation even though they have not recognized it officially yet. We’re part of the people that believe in it and would love to see the community supporting this choice - it’s a good way to ensure healthy evolution of a platform like this. I think BSL makes sense for platforms, but for libraries, we always use MIT or GPL as I think it’s more suited. We’ll definitely blog about how it goes with this license, it’s a topic I hold at heart.
From the license:
Am I missing something, or can one do everything except use it?
BSL: You can self host or pay for hosting but not sell hosting to others.
It’s not that simple from the BSL alone, but I missed the concrete parameters to this use of the license:
For an unmodified BSL, any “production use” is outside the grant, but Meli grants “use” outside of running a service as specified (it appears they allow a non-commercial service though).
It may be a good idea to design a “composable” set of shared source licenses like Creative Commons did with their licenses for creative works. E.g. SourceAvailable-ProductionUse-NoSublicensing-NoCloud.
Thanks for clarifying. This does make sense!
Looks nice; although one of the biggest advantage Netlify gives me that I don’t need to host anything, and that it’s just “commit and forget”.
I wrote zsrv last year, which I think is another interesting way to deploy (small) static sites: when you compile the HTTP server it will also compile in all the files you want to serve, and then you have a single static binary which contains everything and never needs to access the filesystem.
It’s a really simple “KISS” solution, but it works well for simple static sites (my own site is about 5M in total) and you can deploy it from CI similar to Netlify or Meli.
True ! And if you don’t want to self-host, Netlify is a good option. We’ll publish our cloud platform so you don’t have to host Meli, that’s on the roadmap :) Thanks for sharing !