Episode 23 of "Busted!": Another VC driven company builds growth on the back of a community with the promise to always* be Open Source and after a few years the little asterisk finally kicks in. It says "Gotcha! We don't want you anymore, we now switch to a commercial license"
#Redis just confirms that "permissive" #OpenSource licenses should be understood as "permission to exploit".
A #CLA is a red flag (unless perhaps to a NGO/charity).
Look for projects that chose strong Free, Libre, Open Source protections - such as the #GPL / #AGPL / #EUGPL and a Developer-Certificate-of-Origin (#DCO) rather than setting yourself up.
... do we want to take a bet on how long it takes for #redis to get forked and their business to fold anyway, having caused the damage?
For technology / projects such as this - that have become foundational, widely used, part of the public technology commons - being structured as a "commercially viable" profit-maximizing business is an unsolvable conflict of interests.
These need to be supported collectively and cooperatively, and should be transferred to matching organizations/foundations.
I did a lot for Redis and in the community.
To this day I'm #23 on the contributor list of the main code base. I maintained the docs and several client libraries. I helped run the IRC channel back in the day.
I stopped most of my involvement some 6 years ago.
Sorry to any night owls out there who were affected. TL;DR: Redis has never played nice with outages, and it's... annoying. I'm going to try and git better with documenting these on our github repo, so here are more details:
Here is my toot resume in case anyone has open positions:
Experience: staff software engineer, #backend#webdeveloper, #python, #django, #postgresql, #terraform, #redis, #rabbitmq, #kubernetes, #aws, #gcp
I get things done and worked with pretty much any tech out there. I learn fast, have no problem coding in other languages. I have experience leading teams. I helped growing an engineering team from 10 to 150 engineers. I know how to scale things. My code is resilient and has tests. #fedihire
A lot of my apps require a scheduler, I've always given the option to choose between using #APScheduler or #Celery/#Redis for that. So tempted to drop Celery though because of just HOW MUCH RESOURCES it needs to even work, and when it doesn't work it's all silent about it. In my #helm charts, I could set very low (default) resource limits because they've been tested to work/be sufficient with APScheduler and the rest of the app - because of Celery though, I'd need to set a much higher default.