Mike Perham, creator of Sidekiq, writes about Ruby, Redis, running an open-source business, and keeping dependencies low.
HN commenters link his posts on charging for open source and on killing dependencies, and discuss his advice on Redis use and Ruby memory allocation.
Companies are more than willing to pay for software, but there's little incentive when they would otherwise get it for free and you're asking for a charity handout. I'm sorry but that's just reality. If I were you, I'd figure out a way to earn money off of your project, perhaps by going open core and making a premium version with business-friendly features.
I found these blog posts valuable:
http://www.mikeperham.com/2014/10/01/the-path-to-full-time-open-source/
http://www.mikeperham.com/2013/10/01/how-to-make-100k-in-oss-by-working-hard/
Relatedly, this is why I intentionally didn't make my newest project open source. The project is DataDuck ETL (http://dataducketl.com/) - if it were open source, companies would have used it for free and I'd be stuck maintaining and supporting them for free. Instead, I've already made five figures off of it, and it has only been out for a few months. I'm calling this "Supported Source" (http://supportedsource.org/) and I encourage anyone to follow this same business model. In short, the code is publicly available online, and I'm open to collaborating or receiving commits, but companies need to buy a license to use it beyond a free trial. This is not open source, I agree, but it's similar to open source in many ways, and ultimately more sustainable than open source for certain types of projects.
It's probably too late for your project but if you want to make money sustainably from it, I think you're going to have to move away from the…
I wanted to write this post after the left-pad debacle but I've been beaten to it.
I think we got to this state because everyone was optimizing js code for load time-- include only what you need, use closure compiler when it matters, etc. For front end development, this makes perfect sense.
Somewhere along the line, front end developers forgot about closure compiler, decided lodash was too big, and decided to do manual tree shaking by breaking code into modules. The close-contact between nodejs and front end javascript resulted in this silly idea transiting out of front-end land and into back-end land.
Long time developers easily recognize the stupidity of this, but since they don't typically work in nodejs projects they weren't around to prevent it from happening.
New developers: listen to your elders. Don't get all defensive about how this promised land of function-as-a-module is hyper-efficient and the be-all end-all of programming efficiency. It's not. Often times, you already know you're handing a string, you don't need to vary the character that you're using for padding and you know how many characters to pad. Write a for loop; it's easy.
Note that this is exactly the sort of question I ask in coding interviews: I expect a candidate to demonstrate their ability to solve a simple problems in a simple manner; I'm not going to ask for a binary search. Separately, I'll ask a candidate to break down a bigger problem into smaller problems. In my experience, a…
On the subject of OSS projects on the side, I'm really interested in the dual licensing model - I'd like to have my code licensed under a strict copyleft license so people can see the code, but a more permissive license so businesses can use it.
Based on articles like http://www.mikeperham.com/2015/11/23/how-to-charge-for-your-open-source/ I've figured out the following:
OSS license - AGPL - I'm building web services distributed as docker containers, so AGPL makes sense because it forces businesses to buy a license even if thy just deploy an instance of the service without modification.
Commercial license - this is where I'm stuck. MIT / BSD isn't a good fit because the business is then free to make and sell their own version of the service. What license will allow a business to run my service, and customize it for their own needs if necessary, but not re-license or redistribute it? Based on https://choosealicense.com/appendix/ it seems like the Mozilla Public License comes close, but it forces businesses to disclose the changes they've made - which I doubt they'd want to do.
I don't want to write my own license - anyone know of a good existing license or template? Don't mind buying it if it's less than $100, but getting a lawyer to write one is much more expensive.
Tell the horde OSS != FOSS and also get off their entitlement horse.
By opening your source you’re already in the minority contributing to common good, openly sharing your understanding of how to solve problems with code (aka IP). Making IP free is a big deal — you’re making it free to learn, understand, and advance shared knowledge. You don’t owe anyone making it free to run a business on.
To head off an AWS vs. Elastic situation, where someone else offers your code as a paid service w/o compensating you and w/o releasing their in-house patches (https://www.theregister.com/2021/01/22/aws_elastic_fork/), consider AGPLv3: https://choosealicense.com/licenses/agpl-3.0/
See top comment on that here on HN about 8 months ago: https://news.ycombinator.com/item?id=25834523
---
TL;DR: “How to charge for OSS”: https://www.mikeperham.com/2015/11/23/how-to-charge-for-your-open-source/
There has been lots of discussion lately about Ruby and malloc. jemalloc gives the best results for Server Performance and memory usage [1], but is slightly slower in low memory usage scenario i.e Non Server usage which is popular in Japan. But jemalloc sometimes ( Not sure if this is still the case ) doesn't work well with muslc, used in Alpine Linux.
The Ruby Core team has decided against [2] shipping jemalloc by default, but will use it when it is available. Which ultimately led to some work on SleepyGC [3] and Transient heap [4].
[1] https://www.mikeperham.com/2018/04/25/taming-rails-memory-bloat/
[2] https://bugs.ruby-lang.org/issues/14718
[3] https://bugs.ruby-lang.org/issues/14723
[4] https://bugs.ruby-lang.org/issues/14858
It's not a good idea to use a single Redis instance for both caching and persisted/transactional data (background jobs). For background jobs, you need real-time persistence with AOF. For caching, you want everything in memory, and you need an LRU cache that evicts any old data. This means you should run two Redis instances with different configurations. But in that case, it can be a good idea to use Memcached, which is recommended by Mike Perham [1].
[1] http://www.mikeperham.com/2015/09/24/storing-data-with-redis/