Probably because the dependency scanner the lawyers at his company required be added to the code review system will instantly fail the review if he added an AGPL project as a dependency.
There’s no reason to worry about the AGPL unless you plan to conceal code from its users. Most software businesses take this approach because it’s hard to sell information that is publicly available, and code is just information. Some businesses make money operating software for others. AWS pays on-call engineers to keep RabbitMQ highly available.
Free Software protects the user from the developer. Permissive licenses protect the developer from the author.
A lot of professional software engineers get confused and think of themselves as the “user” when they’re actually more of a middle man.
Because they listen to fear mongering or would prefer to ask nicely that megacorps be kind to their users instead of just using a tool with legal teeth.
#
I'm so frustrated, this product was advertised so many times and it also was "rebrended" a lot. At first it was an API hub, then it became an alternative to AWS, then the author was selling it as serverless thing, now it is Universal Public API Interface.
Author is also know for working on project called micro that changed the license once so you could not use it for any purpose that competes with the project, but it was changed to Apache later again. Such bold decisions of the author and now the creator of m3o service makes one to think twice before trying the product.
Link to the commit: [Update LICENSE · micro/micro@31c1254 · GitHub](https://github.com/micro/micro/commit/31c12547b9cd4a4fd0176b...)
Besides all of that product is bad, therefore doesn't suite for production use cases. A few points:
1. Pricing is dumb. "Unlimited API requests", "1M requests per credit", what does it mean?
2. Community support? Where is the community and the community can answer my questions if you don't have any documentation?
3. Any SLA? No even for Business plan?
4. Authentication and user management. Are you crazy? Who is going to use it? No idea is the data encrypted or not, can I backup it? Do you have failover solution? Again, SLA? This kind of API can't be just used by anyone in any production environment.
5. SMS API relies on credits. Where is the pricing for credits on your website?
6. What about OpenAPI, JSON Schema or GraphQL? JS, Go, Dart and Bash SDKs are not enough. You probably don't have enough resource to cover 99% of the most used programming languages, so just publish OpenAPI spec and let the customers to generate code in Java, for instance, until you finish the SDK for Java.
*Conclusion*
It seems that m3o is just a pile of different API that are supposed to be an alternative to SMS provides like Twillio, some finance APIs, Email providers like Sendgrid, a few products from AWS etc. Yet it doesn't even cover a 1% of the features that those companies do provide.
Please, be responsible for your product, don't mislead your customers. If you want people rely on your product in production put in alpha or beta stage, make it free or let a limited number of users test it, work on every API you want to provide thoroughly, write documentation AND then put sell it.
Thanks for your honest and critical feedback. Let me try to address your questions head on. First let's start with context. I've been working on the ideas behind and around Micro for 7 years now. The first 4 years of which were solo and bootstrapped. It started with the idea of building a "platform for microservices". I spent that initial time focused on an open source framework called Go Micro and then a companion toolkit called Micro. These were what I thought as the building blocks of a platform and my hope was to create a standard in the industry that would lead to everyone building services that could be shared and reused. It was pretty hard going, I burned my savings for a year, then a friend was gracious enough to put his name on the line and sponsor my work at his company. But I was still largely doing this solo coding 18 hours a day in my apartment. Eventually I managed to raise $2m in seed funding May 2019 after failing for the 4 years before that. That changed everything. I was able to hire a team and try to execute on the goal of building a platform for microservices. It also meant massively overhauling the open source project to support that.
The licensing change you're referring to is at a time when we were writing a v3 of the software (again major overhaul) moving from a toolkit to a PaaS like product. At that time AWS was picking up popular open source projects and running them without contributing anything back. I watched the hard work of so many people I knew personally just get lifted and profited from with nothing in return. I also saw them fightback using custom licenses. Cockroach, Mongo, Redis, Elastic, Confluent and others all relicensed to address the issue. I tried to learn from their experiences and my assumption at the time was, we need some sort of new licensing standard and that Micro should adopt something like that too so we don't run into this future problem. I saw Heather Meeker, who wrote most of those custom licenses do something called Polyform, trying to create this standard, so I started to think about adopting it. We had gone from this solo bootstrapped project to VC funded and I was trying to turn this thing into a real platform which meant the project was effectively being totally rewritten and v3 was a massive departure from everything it had done before. It was clear we'd be leaving behind those existing users and so I made the decision to relicense. I used the information I had at the time to make a decision, whether it's right or wrong in the eyes of users, it was the decision I made.
You have to understand, I'm a developer who believed in everything being free and open and doing the right thing in the open source ecosystem. But I had also spent 5+ years giving away free software with little contribution in return, I had one corporate sponsor and everyone else was just using the software filing issues, complaining on slack, etc. I was so grateful in the beginning to have people use something I wrote, but I became resentful of that fact the longer it went on without anyone contributing back. I was personally struggling, mentally, financially, but no one really cares about that side. People just care that you give them free stuff.
So the licensing change was based on a complete rewrite, move to v3 and watching the industry shift. I was in that space, I had to act accordingly. In time as our PaaS efforts failed, it became clear this wasn't going to be a thing we needed to worry about, so I switched back to Apache 2.0. That's the gist of it. People make mistakes, but we're also just trying to do our best. I have more empathy for Solomon from Docker, Shay from Elastic and others now than ever before. None of us are doing things maliciously, none of us are trying to pull a bait and switch, we're just doing the best we can. It's blood, sweat and tears. But you can only know that if you live the journey.
On your frustrations around the rebranding. Startups pivot. What can I tell you. We're quite literally on a website created by someone who built a startup, funds startups, etc. So to have someone criticise that is quite amusing, but I get it. What you have to see from the other side is, it's a 7 year journey, and I'm just building something that's evolving over time, addressing different needs and catering to different audiences. I'm just trying to figure it out and HN is often a barometer for what works and what doesn't. What's mostly changing is just a tagline. Also known as positioning. So I'm sorry it's frustrating. I'm frustrated too. I've been doing this a long time.
On your point about the product. Noted. Look a lot of people like it, some even love it, and others won't get it. I won't try to defend it, I'll just try to address your comments and fix it. We're working really hard, again as a small team, 3 people, a startup, to make something that people love and that actually helps them be productive.
> 1. Pricing is dumb. "Unlimited API requests", "1M requests per credit", what does it mean?
You can make as many requests as you want, there's no cap, but it's charged 1M requests per credit. A credit is £1. You can see this on the pricing page under "API requests" https://m3o.com/pricing.
We adopted a credit model after we had a number of people say that currency fluctuation was an issue for them. We also operate in the UK and having used dollars before it just stopped making sense for us. What's clear to me, dollar denominated requests aren't great, pricing can be just as confusing.
> 2. Community support? Where is the community and the community can answer my questions if you don't have any documentation?
Discord community. If you login there's a link under "Support". If you've done anything in open source or any product that's bottoms up developer led, you'll know community is one of the staples of that, people help each other. And we spend our time on Discord helping people the best we can.
3. Any SLA? No even for Business plan?
Still working on it. We're in beta. We're hoping to get this addressed soon.
> 4. Authentication and user management. Are you crazy? Who is going to use it?
> No idea is the data encrypted or not, can I backup it? Do you have failover solution? Again, SLA? This kind of API can't be just used by anyone in any production environment.
You'd be surprised. I think senior folk won't use this in production yet, but many people otherwise do. People who are looking for simpler solutions. When you talk about data encryption, backups, etc, I'm assuming you're talking about the database which yes is all about the above with automatic failover, but this isn't really something we're going into right now because we're not expecting production usecases yet as you say. We're trying to gauge whether there's an audience for this product.
> 5. SMS API relies on credits. Where is the pricing for credits on your website?
On the pricing page, please scroll down
> 6. What about OpenAPI, JSON Schema or GraphQL? JS, Go, Dart and Bash SDKs are not enough. You probably don't have enough resource to cover 99% of the most used programming languages, so just publish OpenAPI spec and let the customers to generate code in Java, for instance, until you finish the SDK for Java.
Everything is based on OpenAPI spec. We did allow downloads of that spec before but it really didn't make sense for our audience. These people don't care if it's OpenAPI or anything else. They want client libraries. They want ease of use. So I'm getting the feeling like this product isn't built for you which is fine.
> Please, be responsible for your product, don't mislead your customers. If you want people rely on your product in production put in alpha or beta stage, make it free or let a limited number of users test it, work on every API you want to provide thoroughly, write documentation AND then put sell it.
We're not misleading our customers. We talk to our customers. They talk to us. We're pretty transparent with them. No one is trying to sell anyone a terrible product. I think you need to understand the motivation is to help people, not use them. The product was free for 9 months, we moved to subscriptions and then being mostly paid only because all we found was people coming to use it because it was free. As a startup seeing nice high API request numbers and signups was fun but that doesn't pay the bills, it's not a real business model. You get 10k requests free on signup now. Maybe we'll offer free quota again, I'm not sure. But people are paying, so they see value in it, that says enough.
On documentation. I'm trying to build a product that needs zero docs just like consumer products. We're not digging through endless docs to use consumer products, so why APIs? It just doesn't make sense to me. Our goal is to make it absolutely dead simple to use APIs and put all of them in one place. Look it's not going to be everyone's cup of tea but that's what it is.
I appreciate your comments, I hope I was able to address them. I'm not here to argue, you gave your point of view and I'm giving you mine. Without all the information it's just opinions, so here it is.
There is a new trending repo on github where is the link to the list of people who died during the lockdown in Shanghai. https://github.com/The-Run-Philosophy-Organization. The repo itself is mostly about why and how to run from China.
