61–70 of 328 posts
Counter argument, don't deploy your code on other people's hosts.
Earlier quoted context omitted.
You can sell a library just as well as any other piece of software I think.
Stealing a library is easier than stealing a service.
This is very sound advice. That being said it's incredibly hard to follow this advice in environments which encourage a polyglot stack and 'the best tool for the job' mindset. The moment you have more than one language in your stack it becomes easier to build services than to maintain libraries in each language. You can of course write native C libraries with bindings to different languages but that's a bit weird. It…
Not everyone's cup of tea, but on Linux gobject-introspection allows for automatic or semi-automatic generation of bindings for X languages. .NET also -- and this is only my interpretation -- is following that path.
I like the approach and it seems to be definitely better for everyone, but how you monetize a library?
Does everything have to be about money? This is "Hacker" News, not "Monetize Everything" News.
We have voluntarily destroyed lots of economic growth and plunged millions into extreme poverty because of a virus that is not especially bad when compared to historical pandemics.
First, my objection, though. Pushing this "to the users" is in no way easier to support. It is easier to abandon, but support is a different thing. You will have support contacts. And, due to the distributed nature of the deployment, you will have a much harder time isolating your code from the environment it is in.
With a service, it would be a lie to claim this is easier, but it is a bit more approachable.
Now, a difference, I believe, really comes in to whether or not there is state associated with what you do. If there is, and it is not something that makes sense to move close to the user, then a service is pretty much required. If there is no state, make sure that is not artificially done by just moving to all state being managed by the user.
1990s advice on a 1990s website. It's the opposite. We need to move away from package hell by splitting our work in two opposite directions: on the one hand, we should move back to large, effective standard libraries; on the other hand, we should move toward more services, fewer library packages. A project shouldn't need more than a few packages, usually for something like a database connection protocol. Working with…
You are in my opinion a bad developer for having that attitude. Being able to know when and when not to use a library is an important skill. As with everything, it's a trade off and you seem to not be aware of one side.
I like the approach and it seems to be definitely better for everyone, but how you monetize a library?
Does everything have to be about money? This is "Hacker" News, not "Monetize Everything" News.
> A service has constant administration costs which are paid by the service provider. A properly designed library instead moves these costs to the users of the library. I agree with the articles point, but this introduction, right there, is why it's not happening. SaaS turns your startup into a unicorn and yourself into a rich person. Or at least that's what you are hoping/aiming for. A library is not going to make y…
Only on the FOSS world, because it is the only way to force devs to pay. There is another alternative universe where commercial software, including libraries, gets sold.
> A service has constant administration costs which are paid by the service provider. A properly designed library instead moves these costs to the users of the library. I agree with the articles point, but this introduction, right there, is why it's not happening. SaaS turns your startup into a unicorn and yourself into a rich person. Or at least that's what you are hoping/aiming for. A library is not going to make y…
Is SaaS really the only viable (or "unicorn") business model? Do people not sell software licenses anymore? (In theory nothing prevents you from making your license require recurring payment as well)
In my opinion this is a feature, not a bug, but the business reason is clear for why all commercial software is moving towards the SaaS model.
> A service has constant administration costs which are paid by the service provider. A properly designed library instead moves these costs to the users of the library. I agree with the articles point, but this introduction, right there, is why it's not happening. SaaS turns your startup into a unicorn and yourself into a rich person. Or at least that's what you are hoping/aiming for. A library is not going to make y…
The article's author seems to be making an indirect reference to Moxie Marlinspike (Signal) "ecosystem is moving" essay[0].
If so, Moxie Marlinspike's method for becoming a billionaire by creating non-profit 501(c)(3) organization and providing Signal's source code is a very strange way to cash out of a unicorn.
And btw... even though users/developers have the Signal source[1] which enables them to create an alternate chat universe that's not dependent on Signal's official service/servers, that isn't good enough. They still want to federate[2] with Moxie's servers. This aspect isn't addressed by op's (catern) article.
In other words, having a library (or even the full client+server source code) doesn't really solve the users end needs. It turns out that many place more importance on the service than the library.
[0] https://signal.org/blog/the-ecosystem-is-moving/
[1] https://github.com/signalapp
[2] https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
[3] my comments about it: https://news.ycombinator.com/item?id=20232499
EDIT to reply: The first IKEA business in 1943 was for-profit. The non-profit foundation (Stichting Ingka Foundation) was formed later in 1982 so the owner could take advantage of tax efficiencies. I don't see how IKEA's opposite timeline has any relevance to Marlin's playbook to become a billionaire. Is there a real case study of a 501(c)(3) non-profit entity tricking everyone into a bait & switch and minting a new billionaire?