Starting today, strategizing the removal of critical dependencies owned by Block. It's not a knock on the code, but something that everyone should consider as Engineering was affected at a higher rate with the 40% employee layoff. Libraries critical to your business operations are not likely to have the same support and updates they once did. We have also not had any assurances that the open-source nature of the company and its existing operations there will be maintained. -- Edit -- Out of a deep respect for the situation and people involved, I have removed named packages. There is some bad speculation going around that is not my intention and certainly not a reflection of the people affected here whom I respect deeply. Please read this edit knowing that there are people outside of Block contributing to work under the Block GH accounts/names. People who believe in that work beyond their employment, if ever. My intention was for people to analyze the costs were something to happen, knowing your mitigation strategy. Something of this scale has not worked out for OSS in past instances. Unlike last time(s), I am seeing a ton of engineers broadcasting how dedicated they are to continuing that legacy. In that regard, I have no trouble trusting the engineers doing so. It tells me that even if something were to happen that would require change, that the contributors would give the Internet appropriate time and messaging. -----
This feels like a misunderstanding of what open source is designed to do. Libraries like OkHttp, Retrofit, Moshi, SQLDelight, etc. aren’t “owned dependencies” in the traditional vendor sense. They’re open source specifically so they can outlive any one company. If maintainers change, the code doesn’t disappear. It can be forked, patched, funded, or community-maintained. Many of these repos already have multiple approvers who either never worked at Block or are former employees, which is exactly how healthy OSS governance is meant to work. Replacing mature, battle-tested libraries because of hypothetical organizational shifts isn’t resilience — it’s churn. The real resilience move, if something is business-critical, is to contribute to it, mirror it internally, or support its maintainers. Open source works when teams act as stakeholders, not just consumers.
Aren't these libraries generally very stable at this point? And very forked as well with lots of first and third party contributors. I am not super worried about them.
Are scammers with LLMs lining up to provide alternatives and snatch the migrating market share (like with discord alternatives) ?
Commenting for my network to consider.
From a legal standpoint is there anything stopping us from forking libraries such as Retrofit and maintaining a Block-free cousin of them?
This is very good advice. We see numerous examples of how Open Ource projects get enshitified: - Corporate based commiters laid off or leave company - Sponsoring company loses interest - Sponsoring company gets greedy and creates a dumbed down free tier (e.g. Puppet) - The above cause a community fork None of these mean the project is dead but you want to consider the ramifications early to avoid panic later.
Paparazzi is another
Retrofit and okhttp is my bread and butter. Well do you have great alternative in my mind with active community other volley.
Im suprised Google just didnt adopt Retrofit like they adopted dagger 2... Maybe they are still thinking about those 5 engineers still using Volley 🤔
Fanatics•8K followers
1moJust citing that basically everyone inside of Block confirmed externally that Eng was way more affected with 60-70% of all Eng being gone. I knew yesterday evening that it was over 50% and many OSS maintainers being let go. This is so much worse than we thought.