pull down to refresh
Maybe I come off as confrontational - probably I am, haha. But it's not personal, so please don't take it that way.
I'm not saying that everyone should review code. If you want to trust the process wherein others review the code, then you review the process. This is a perfectly understandable thing for people that don't read the code. But I fear that this too is too much for many. How sovereign are you if you didn't test the process you trust? Do you like finding out that 2 people that did a lot of work on reviewing code - the ones that protect the integrity of the software and therefore are needed for the process - are feeling worked against? Doesn't matter that these aren't the most polite people that ever existed; you simply need people that do the work, and then disagree with you - that's also what Adam Back was trying to say, I think, in the quotes of the article.
Thing is, all this happened years ago. I remember it clearly because there was a much larger process thing going on around that time, about "maintainers with a specific portfolio". This type of subject area focus works with Linux as that's a hierarchical structure, but it doesn't work with orgs without centralized leadership. Everyone has their expertise but top tier maintainership cannot be discriminative and you don't get to work on the things you like as a maintainer. You can if you're a lieutenant of Linus, you cannot if there is no hierarchy and you're one of the n top dogs, because you share the burden between everyone for the whole, not just for your own shop. Everything that goes wrong is on the whole group.
And this exactly is a process thing, so it is of interest specifically for those that don't read code. For me, it doesn't matter much because I just read the code (though I was interested in the organization because I have a FOSS non-organization of my own to reflect.) So if this is realized only now, then the process wasn't monitored really, and it just becomes some blame game drama (no matter what the author intended.)
Also note that this shouldn't in any way be a disqualifier of the competence of maintainers in terms of maintenance. Just the organization per definition sucks if it's unorganized. I don't know anyone that got this right. I don't know of any project of significance that got to be unorganized, or democratic, or otherwise decentralized. And it's because the repo structure forces some centralization. IMHO, the only way to decentralize (the protocol) is to have "competing" implementations, not decentralize a single implementation. But... maybe I am wrong. Multiple implementations isn't a silver bullet either.
So I speed-read through the article (because I find drama boring) and it sounds like the usual FOSS "clique" drama where you can replace the names and project with almost any other popular project and its players, given it is a project where a lot of hope and passion lives, there is an insider group and some money is changing hands.
The big problem in this is not whether or not this happened. The problem is that many devs would have been ok with laanwj being BDFL with emphasis on the B. But, Bitcoin is too big for a BDFL. Bitcoin is also too big for Bitcoin Core. You cannot cast people out from Bitcoin, if it is to solve any problem. The drive that tries to rid the world of the SPOF - that Voskuil alludes to, and ariard... and Jimmy & co recently too - is ultimately what will make or break Bitcoin. If Bitcoin truly is a protocol, it's only a matter of time for this to be solved.
What I am less amused about: if anyone is surprised by this, then have they read the bitcoin/bitcoin discussions on the repo sometimes? Before the drama carried over to social media? If not, why care now? It's not like you're reviewing anything anyway then, so you're anyway at the mercy of some process that you gaslit yourself into believing protects you.
You: "You have to send a tx from their app to recover"
Steve: "That is not lock-in"
Steve is right though: this is not lock-in...
... it's slavery disguised as bulshytt.
(I really enjoyed re-reading Anathem, lol)
Okay?
- What magic secret can live in the open?
- What magic secret (container?) can sustain amnesia/wear, fire and flooding?
- What magic secret cannot be stolen?
- What magic secret is persistent and absolute in backup?
- What magic secret is non-physical?
- What magic secret is so magic that you don't have to explain it?
Awesome! Yeah... blixt giving me max sovereign private channels and is more stable than Zeus.
I couldn't keep up with the Zeus release cycle either as too much stuff gets added making review pressure too high for my production use. Maybe I should just set it up for mutiny and play with it from time to time, but the problem is that there's only 24h in a day.
So I'm happy w/ Blixt. It's not a highly tuned UX but that is fine - the pain isn't that bad.
My main LN spending wallet is Blixt. I like it because it is stable and performs well. A bit high on the battery drain if you keep it on all the time, but overall it is awesome.
For SN I am currently testing Shockwallet. It's overall a good experience. CLINK per-connected-app budgeting seems to work well too!
transition. the favorite word at GitHub ever since acquisition. Announcements of transitions often come paired with either the theft of your data, or, when the data is no longer worth much, a price tag.
As my buddy used to say every time even the most minuscule thing went not as planned: never let a good crisis go to waste.
Text:
Yesterday,@fgthiel, CEO of MARA, announced the MARA Foundation. What was celebrated in Bitcoin open-source circles seemed to be met with skepticism from some shareholders.
After 9 years working full time in FOSS, and spending a lot of time on podcasts and conferences encouraging people to pursue it as a career path while advocating for more diversity and meritocracy in funding, I was disappointed to still see this disconnect.
In this post, I want to try to make the case that throwing money at open source is an investment, not philanthropy or a marketing stunt.
Here are the talking points I use when making this case to skeptics, whether inside a company or from the outside, which you can use to advocate for open-source funding or better articulate the value of your work as a FOSS contributor:
1. Upstream Decisions, Downstream Impact1. Upstream Decisions, Downstream Impact
Your business depends on open-source software. As these projects evolve, technical and strategic decisions are often made outside your immediate line of sight. In most cases, you only notice them once they surface downstream as limitations or breaking changes your team now has to work around. By that point, the direction is already set.
Open source developers operate upstream, across companies and projects, and often surface issues well before they become operational or commercial problems. Supporting them provides early visibility into protocol changes, architectural decisions, and emerging trends.
2. Talent pipeline2. Talent pipeline
Grants enable access to global talent unconstrained by hiring jurisdiction or headcount limits. While you cannot hire everywhere, you can give a grant worldwide. Over time, this creates a pipeline of potential future hires.
Open source makes high-signal people obvious. You see who takes ownership, who ships, and who operates without waiting for permission.
If you’re hiring, especially in early stages, that signal is far more reliable than anything on a resume.
It also gives access to talent that would otherwise be unreachable, contributors who are not looking for traditional roles or are outside your hiring scope. Even when they don’t join, you build long term alignment and relationships.
Over time, this compounds into both a talent pipeline and a reputation within the developer ecosystem.
3. Complement to R&D3. Complement to R&D
Funding a small number of independent contributors provides leverage comparable to a distributed R&D team at a fraction of the cost of internal hiring. These contributors work at foundational layers where technical innovation in the industry originates.
Direct grants create strong working relationships that passive sponsorships or third-party funding do not. Close collaboration with builders provides early visibility into where the technology is heading. This early insight is essential for meaningful innovation.
A grant program does not replace internal R&D, it extends outreach into upstream work that internal teams may not have capacity or specialization to pursue.
4. Small operational and legal overhead4. Small operational and legal overhead
Operational risk is low. Established grant frameworks already exist within the Bitcoin ecosystem. Grants are structured as time bound agreements with independent contractors, avoiding employment or HR liabilities.
Oversight requirements are minimal and can be limited to quarterly updates and a single internal point of contact.
To reduce setup friction, you can reuse existing legal and compliance templates, drawing from the experience and documentation of Spiral, a subsidiary of Block, which has funded over 70 developers since 2018, as well as Bitshala, HRF, Maelstrom, OpenSats, Tether and Vinteum.
ConclusionConclusion
Your company can remain a downstream consumer of open source infrastructure or become an active participant in the foundations you depend on.
A FOSS support program reduces upstream risk, brings you closer to active development, and builds durable relationships with the people shaping the systems your business relies on.
For a budget comparable to a single hire, it expands your R&D surface area globally with minimal overhead while strengthening your position within the ecosystem.
Open source works because it is rooted in meritocracy, and the fastest way to kill it is to distort that.
The way to counter that is not less participation, but more.
More independent, economically rational sources of support, and more participants acting in their own self interest.
I'm just another a-hole that took the "verify" part to heart really. You see, the most amazing thing in the entire story of jonatack is that it took 2 years for him to be really worked against. I wouldn't last 2 weeks before being puked out.
Agreed, but the keyword in there is
drama. I truly do think that the process should be monitored. And wrong moves be called out. Because you don't establish trust during the good times, but in those of crisis. And you still want to verify in an ongoing matter anyway, this is Bitcoin.Or at least care more about informed opinions.