For pretty much my entire career, I've been driven by the idea that software helps people solve problems; and a rational way to be an ethical person is to make sure that software/data is free/open.
A huge part of that is democratisation of tools - gatekeepers, people in power, people with money should not get to control what the people without these things do or say.
In my professional life, the ideas of open standards, collaboration, free exchange of information are regarded with suspicion - not just from managers or bean counters; but even from other technical staff.
These concepts seem completely alien; so a big part of why I'm successful is because often I'll be able to go and look at what a problem is, and just do the 15 minute fix; have the conversation introducing two groups with mutual interests, etc.
This worked tremendously well when I presented the same interests as the users of the software, but falls down in a consulting/multiple customer situation. The result is I end up under intense pressure, because there is a short termism mindset: why didn't I try to sell a customer on paying for a few customer development hours? Did we just give away some kind of magical value for free?!
It's been a very long journey of repeatedly hammering home the end to end costs of quoting, negotiating, acceptance, invoicing, billing, scheduling, BA work, QA work, deployment and support requires such a significant overhead that it simply isn't worth it for the tiny things. Even if each step "only" takes 10 minutes, that represents 9-10 conversations with two participants at each step - 200 minutes of collective time invested just to reach agreement on doing the original 10-15 minute change.
When the charge out rate is a minimum of two hours; every job less than 4 hours is a money loser and frustrates customers.
On the flip side of it, the end to end process is hugely resistant to change or optimisation, because it's "only" a 10 minute process at any given step; so why spend time or effort on it? That'll cost more, right? And we're so busy repeatedly running this pipeline for low value jobs with a high error rate that we simply don't have any time to do it right!
What I inevitably end up doing is deliberately ignoring this broken process - when prudent - as delivery of a small fix has the best outcomes for all parties:
Happier customer (more willing to pay for the big things when it matters; they feel heard and listened to, even if you don't get it right).
Product offering just "works", decreasing support costs across entire customer base by 0.1% per big fix.
Even if you get it wrong, provided it is easily reversible; the economic cost to all involved is frequently *less* than the "proper" process.
Despite all of the rational, provable logic underpinning the above; it never sticks.
The reasons for this are generally down to anxiety/insecurity/a need for control. Loss aversion/not being in charge of what is happening leads to panic about potential loss, interference and manipulation, changing or inventing new rules that simply increase the actual underlying costs.
It truely doesn't actually matter for someone with this mindset if they "choose" to set fire to a pile of money; because the most important thing is not the money despite what they claim, but simply being able to feel like they are "making progress" or "taking ownership" - this comforting feeling is the most precious thing in the world, to get rid of the anxiety gnawing at them.
What worries me is that as people trend more conservative as they age; and more open source maintainers my generation or older than not, this kind of thinking seems to have become more prevalent over the last few years.
In open source, it's not about money; but it is about power and control.
Worse; what started out as well intentioned observations around burnout, demanding users, lack of payment in open source has now morphed into "permission to act only selfishly".
While this can be good for some who chronically do not do that (people pleasers); there is a contingent of folks who take these observations and use them as a badge of entitlement.
An example:
"... As an author, you have the right to tell anyone barking commands at you to get bent. Lock the Issue. And close it as "Not Planned." Things usually end there. But if they have the gall to make another Issue to bark some more, block them. Screw em. You have the ultimate say, and total power, over the things you solely maintain. They've got nothing but the ability to talk to you until you decide to take that away from them too."
I have no problem with the advice to be assertive, but the descriptions of "total power", the "taking away" language are troubling.
When I contrast this with my motivations for open source/open data, this seems the polar opposite.
Another common theme is reinterpretation of many open source licences "no warranty, express or implied" wording as "no duty of care or social responsibility".
No, you do not have to provide support for end users or babysit them. That said, in my view, you need to take ownership or be accountable, if your software or efforts are detrimental - not from a legal point of view, but from and ethical/moral one.
I feel like these patterns have increased, social spaces for communities have vanished, and now open source are hyper vigilant to reject contributions - they don't want to end up as the next xz, do they?
Against this backdrop, I'm struggling. I am probably, due to age, stress, etc far less tolerant myself whenever it feels like bullshit/anxiety/power hungry folks are screwing with me.
I've had three major moments in the last 12 months where I have turned on a dime from eager to contribute (while often ignoring social norms), to coldly angry.
The first was alltheplaces - the overwhelming majority of folks were welcoming, and even if they didn't love the amount of noise that occurs when someone comes through and tries to learn a completely new framework plus review the entire backlog; I felt like the majority of them felt the same satisfaction when they got to merge a pull request or close a ticket that I experience.
One contributor though was an exception - a bit standoffish, maintaining a complex library area; disagreeing seemingly just to win a discussion rather than consider others. Anyone - not just me - who was high output/senior/engaged would get comments shutting down ideas, maintaining the status quo, etc.
Against this backdrop I made a small, but useful change in this core library area they were the owner of. The CI checks were green, the review process was fine, it went in; and... there was an edge case not initially detected.
No big deal, right? This isn't life or death, it's one week of 52 with a minor data problem for a small % of scrapers. Add a test, fix the bug, move on. My work week started and timezone issues meant I couldn't just pick it up right away.
What happened instead (this is my perception at least) was insistence on ripping out the changes entirely, never to be brought back. Quantifying the impact? Couldn't be considered, it was a "HUGE PROBLEM"!
What broke me was the project lead buying into this narrative, rather than pausing to assess the situation.
The net result? My changes reverted; and my contributions stopped dead when my enthusiasm died. I went from being an active member who would have ended up a long term maintainer.
The next was the home assistant project. I maintain a few forks of things, it's a complex project with lots and lots of bug reports. The heavy use of mocking in unit testing in a strange architecture has been (surprisingly for me) a bridge I can't cross, without help.
I put in a lot of work doing community support, issue triage, and started looking at ways to solve the meta problems of timely code review, meaningful feedback, etc.
I'm definitely not the first person who wants to help like this; but the core home assistant team are extremely hostile. Fair enough, they have a larger scale than I have ever dealt with and not enough resources; so I can give them some leeway. I decided to ignore the resistance, as it was just tired people trying to keep control - and generally, technical people stop caring about rules being broken when results or outcomes are better.
What broke me here was when I found a simple bug, and fixed it quickly with the GitHub web editor. I started a draft PR, and was focusing on trying to write a simple unit test to prove the fix.
The PR had been open less than 3 minutes, as a draft, before someone from the core team starts complaining the issue template isn't filled out and they don't accept things without testing.
I decided not to argue, beyond pointing out the PR was still being drafted. One reviewer, jumping the gun, no big deal, it was clearly just something that appeared right as they decided to start doing code review; and they rushed straight to the quickest way to say "no" - this happens sometimes.
But then they lectured me about testing. I had to stop writing the unit tests to argue with them on the pull request; because them being right and enforcing an unwritten rule was apparently the most important thing.
Again, what made me leave was not the one person starting an argument - it was the second, more senior contributor joining in to tell me I was wrong to start drafting a pull request and writing test cases; and inventing on the spot a rule.
This one I bit back on; finishing the PR, tests, etc then withdrawing it. All of these organisations publish the same code of conduct; but none of them actually seem to have read it.
Net result, I will never willing submit another pull request to home assistant core in my life.
The third was recently. After picking up snipe-it at work and recommending it heavily; I put some time into reviewing the backlog and documenting small, but trivial to fix UI bugs.
Turns out, when your dev installation instructions are wrong - just turn your production into a dev environment! Let's ignore the fact that doesn't work for docker deploys, despite 5 different sets of dockerfiles, dev scripts that contained half commented out stuff, an installer bash script, that repeated this all again, it's hard to contributors to make deep, well structured PRs from day 1.
The result: I regression tested effectively every form control and fixed a mountain of small, HTML only UX bugs.
These got slowly reviewed and merged, great, no problems then, I'll pick up something more substantial.
What followed was:
- A weird interaction on a ticket about W3W, vs just putting a lat/lon on models with address fields. Like, the use case of an address having a lat/lon even if it didn't have a street address made no sense to the maintainer (mines, remote, rural, anything on ships or trains that move)
- I got half way through a beginner/intermediate pull request only to be told "oh that's being worked on", but not publically or with any indication like the ticked being assigned/commented on/etc. Fine no problems, I've pushed my WIP branch and will leave it.
- I start a more complex, but still intermediate change to add lat/lon to two models. I find gap after gap, missing tests, components not reused, etc; so document them as "later scope" while I work. I have everything in place and have added a final test, where the build should go green, so I mark it as ready, pending a green build. A few minutes later it fails, so I flick it back to draft. I get a "it takes me a lot of time to review your contributions". Oh rubbish: me adding... "required" to an input tag! is not going to burn hours, even if it's done in many, many spots. It's a ten second review plus check of CI after the first one. Worse was the admonishment for even having started working on the feature they didn't understand, because they were running a "business".
That one infuriated me, because I'd just spent the last 24 hours fighting their broken dev setup tooling, and they seemed to have completely forgotten what open source is meant to be.
So, rather than argue I've decided to hard fork the project; and nuked the various pull requests I had in the pipeline.
This is a bit hostile, but fuck 'em. If they want to dictate where my labour and passion project efforts goes, they can pay me a salary.
Instead of just being reasonable and engaging, they now have a fork which will compete with them; and if they want to adopt any of the changes I'm doing they can deal with the merge conflicts and cherry picking - that's an order of magnitude more effort than review approved + merged or similar pull requests.
What seems ill considered on their part is they can't keep up with me as a single contributor hacking for a day or two on a holiday period, writing clear; concise focused pull requests of very low complexity.... Yet they do this full time as a gig. They have objections to using linters, code style tools, etc and will probably continue to do so. The down side of that for them is this is a common "quick win" that basically fixes up every mixed tabs vs spaces, layout or other problem.
The cost of adopting changes back upstream are now orders of magnitude more difficult than even just cherry picking.
Even worse (and this amuses me greatly), this project is GPL'd. If they want to add any of my contributions, they can't take the product closed source; they have to clean room rewrite them.
If I choose to solve the problems left open for years in their backlog, faster than they do; their customers or users are absolutely free to come and experiment on my bleeding edge develop branch.
Usually if I do this, it's to improve the health of the ecosystem, and if the original project morphs into something else, that's fine. Happened with localtuya, fat free crm; jQuery tipsy, likely to happen again with ha_tuya_ble (turning that into an organisation and considering many forks, inviting maintainers to band together).
But not this time. I'm sick of short terminism and the productization of code and data. Software isn't apps spamming you with ads every 42 seconds; it's a tool for everyone to use; and it's value comes from creating new connections, interoperability, and extending your power as a human.
That's what open source is to me.
