Open source projects frequently face a “silent crisis” where critical software is abandoned, or “goes end-of-life” (EOL), because maintainers become burned out by the overwhelming demands of unpaid labor, security vulnerabilities, and, more recently, a flood of AI-generated spam pull requests.

Examples of FOSS projects impacted by Burnout

Here are notable open-source projects that have shut down, been archived, or faced severe disruption due to maintainer overload:

• Ingress NGINX (November 2025)

  Status: Retiring (no security patches after March 2026).

  Reason: Despite being one of the most popular Kubernetes components, it was maintained by only a few people working on their free time. In the two years this concern has been publicized, almost nobody has stepped up to help.

  Source: https://www.theregister.com/2025/12/02/ingress_nginx_opinion/

• FFmpeg (Fall 2025)

  Status: Pissed off at Google & https://x.com/theo (Twitch Creator?)

  Reason: Another piece of critical open-source infrastructure, FFmpeg regularly gets bug reports & feature requests by corporate users who are unwilling to contribute in a meaningful way.

  Source: The conversation on Twitter ending with

  Also, https://news.ycombinator.com/item?id=45891016

• External Secrets Operator (November 2025)

  Status: Froze all updates. (Has since resumed releases - Excellent example of how systems can evolve through moments of crisis)

  Reason: Four main maintainers burned out simultaneously, leaving only one active contributor. This occurred despite the project having corporate sponsors, highlighting that “money doesn’t write code” when the human team is exhausted.

  Source: https://github.com/external-secrets/external-secrets/issues/5084

• XZ Utils (September 2024 - near-shutdown)

  Status: Almost entirely taken over by malicious actors.

  Reason: The original maintainer, Lasse Collin, suffered from severe burnout and mental health issues, reducing his ability to care for the project. Malicious actors, under the name Jia Tan, exploited this, using fake accounts to pressure him, eventually gaining trust and commit access to insert a backdoor.

  Source: https://news.ycombinator.com/item?id=39891607

• Node-pre-gyp (May 2022)

  Status: Maintained in a “limbo” state for nearly two years.

  Reason: Primary maintainer Dane Springmeyer announced he was stepping down after nearly a decade of handling this critical tool in the Node.js ecosystem, causing a backlog of unresolved issues and security concerns.

  Source: https://github.com/mapbox/node-pre-gyp/issues/657

• Faker.js (January 2022)

  Status: Deliberately corrupted by the author.

  Reason: Author Marak Squires broke his own library and replaced it with a message saying “Pay me” after growing tired of maintaining a widely used library for free, used by Fortune 500 companies.

  Source: https://news.ycombinator.com/item?id=29863672

• Spree (2014)

  Status: Abandoned by its original, sole maintainer.

  Reason: Ryan Bigg, the sole maintainer of the e-commerce project used by major companies, found the daily demands “insurmountable” and affecting his mental health, leading him to stop maintaining it.

  Source: https://archive.is/vQds4

Examples of FOSS projects impacted by AI Slop

Several major open-source projects have taken action against a deluge of low-quality, AI-generated contributions—often referred to as “AI slop”—that have overwhelmed maintainers with fake bug reports and, in some cases, paused external contributions.

Here are the projects identified as having taken, or considering, such actions:

• curl: Lead maintainer Daniel Stenberg announced the winding down of the project’s bug bounty program in January 2026 to combat a “torrent of AI slop” and, specifically, to remove the incentive for submitting “crap, non-well researched reports”. The project was receiving multiple, often inaccurate, AI-generated reports daily.

  Source: https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-slops/

• Tldraw: This project paused external contributions in January 2026, explicitly citing issues with AI-generated spam and low-quality PRs.

  Source: https://news.ycombinator.com/item?id=46641042

• QEMU: This virtualization project adopted a formal policy in 2025 to reject all AI-generated code contributions. The decision was driven by legal concerns as AI-generated code may not satisfy the copyright and licensing requirements needed for official inclusion.

  Source: https://shujisado.org/2025/07/02/how-can-open-source-projects-accept-ai-generated-code-lessons-from-qemus-ban-policy/

• Ghostty: In January 2026, the terminal emulator banned all unattributed AI contributions. Under its updated policy, “drive-by” AI PRs are closed without review, and users submitting poor AI-generated content face permanent bans.

  Source: https://news.ycombinator.com/item?id=46730504

• LLVM: Similar to curl, this project reported being forced to wade through an increasing amount of AI-generated junk to find legitimate contributions.

  Source: https://news.ycombinator.com/item?id=46440833

Why the FOSS community is under attack

The FOSS community grew organically out of a small group of professionals & academics, starting way back before the internet even existed (Actually, I don’t have evidence of this. I know internet was developed in the early 1970’s as ARPAnet & I assume that source code was freely shared even before then.)

In a small group, social norms can be enforced through social means.

So the FOSS community was able to develop a very idealistic set of social expectations, where there was no need for gatekeepers & contributions could be reimbursed through recognition alone.

As the technical community scaled & diluted into popular culture (& as open-source projects became the backbone of corporate products), the need for gatekeepers (project maintainers) increased while the reward for gatekeeping plummeted.

Up until the invention of LLMs, this remained almost manageable: many maintainers found ways to be reimbursed for their subject matter expertise in a manner that they found acceptable. However, in cases where the emotional rewards were not actually adequate or the demands made were just entirely too high, burnout occurred.

LLMs make this situation much, much worse by massively increasing demands for support as well as reviews of pull requests & bug reports, while also seizing the attention economy that reimbursed many maintainers financially.

My Proposed Solution

A universally accepted unit of value measurement: Money.

Without a quantifiable unit of value, there can’t be any enforcement of economic exchange. You can’t regulate demand by increasing prices & you can’t ensure that maintainers receive the rewards for their efforts that keep burnout at bay.

The cause of AI slop spam & corporations parasitically relying on open source is both due to a lack of economic enforcement.

Enforce that value of maintainers’ time & effort must be demonstrated & these issues will vanish almost instantly.

Answers to Expected Questions

• Q: What about those brilliant, but indigent students trying to gain recognition through their first PR? Or security vulnerability reports, which we seek to financially incentivize?
  A: Enable people to gamble on whether a PR or security vulnerability is worth reviewing. This is the perfect problem for a prediction market. Bug report rewards may need to be slightly increased to balance out increased cost of submission.

• Q: What about when we get too many security vulnerability reports, like FFmpeg was receiving from Google?
  A: A crowd-sourced bounty system would help maintainers determine what the user community believes should be prioritized.

• Q: Will financial reimbursement for open source contributions complicate my taxes or government benefits?
  A: Use a system that enables your contribution reward to be redirected to the nonprofit of your choice.

• Q: What alternatives are there to money?
  A: https://github.com/hanzili/slopscore has some good ideas for identifying spam based off of user metrics, but I’m not aware of solid alternatives for resisting burnout or corporate parasites.

• Q: Does an implementation for any of this exist yet?
  A: I have a fledgling repository here for proof of concept & dogfooding. Other similar projects I found included Gov4Git, which focuses more on consensus mechanisms, & DRIPS, which focuses more on sponsorship (although their Ethereum infrastructure could be very useful)

That’s all I got. Thanks for coming to my TED talk.

Oh, and I’m looking for work as a systems designer. You can check my resume for implementation details that I’m familiar with, but I’m confident I can learn any language or framework. I’m particularly interested in improving human organization through performance metric & incentive modification.

One of the big take-aways of that article is that a credibility network built through LinkedIn recommendations is one of the strongest possible safeguards against scam artists trying to steal remote jobs.

But the value of credibility networks doesn’t stop there: since any credibility network that actually wants to be credible has to avoid contamination by bots, you automatically get a network of strong, human signals for products & services once this problem is solved.

One of the areas that I really want to see a credibility network take off is in the arena of politics, especially if I can integrate that credibility network with Pol.is.

Another area where I think credibility networks could enable a more authentic & individualistic approach is in education.

An advisor of mine & I actually think that we have a potential solution, one that could be built on the Ethereum blockchain for some serious transparency & credibility of its own. Who knows? It might even be one of the foundational platforms of Web3.

If you have been looking for an actual socially positive service built on blockchain tech or are interested in a potentially radical reinterpretation of American politics, then hit me up on LinkedIn, Twitter, or any other platform that Google will happily inform you I can be found on.

I’m looking for feedback, questions, technical critiques, & collaboration.

As always, let me know your thoughts!

I hope to hear from you soon!

Scam artists, some from North Korea, are targeting remote jobs for salaries & corporate espionage & my insider experience suggests that hiring companies could be doing a lot more to defend themselves against scammers. See my recommendations below!

The Start of My Adventure

At approximately 11:56 AM on December 9th, 2025, while I was browsing the Internet on my laptop at my girlfriend’s apartment, I was contacted through Slack on the ReactOnRails Slack workspace by a man who said he wanted to discuss a great opportunity with me.

Since I was a little manic at the moment, I agreed to video conference and send him a Google Meet link. On Google Meet, I found myself talking to an Asian man, possibly Korean, with purple colored hair, who used the username Samuel Miller. This man first requested a link to my LinkedIn profile, which he quickly reviewed. He then informed me of his opportunity, which he described as a “work proxy service”: he said he connected to United States developers with developers overseas, who would work under the table, enabling the United States developer to acquire multiple jobs. Income from those jobs would be split 30% to the overseas developers, 30% of this man (Samuel Miller), and 40% to me. He asked if I felt comfortable with this and I assured him that I was here, then he sent me a phone number and asked me to connect to it on WhatsApp. I did so and then I was sent a message that he said out loud.

However, in hindsight, I believe that I was communicating with someone else through WhatsApp as their English fluency was flawless while the person I communicated with on Slack skipped some words and had to ask me to clarify my statement that “I’m curious”, which was my initial response to hearing about this great opportunity. I was then sent a résumé through WhatsApp and the man on Google Meet asked me if I would be comfortable using the name and details of the résumé during an interview, which he said that he had already scheduled for me. Again, I assured the man that I was comfortable with all the details I had received thus far.

The man then shared his screen on Google Meet and showed me a weekly calendar full of appointments, then asked me when was the soonest that I could start. I told him I could start the next day. The man then ended the meeting, saying that he look forward to working with me. Shortly afterward I was asked on WhatsApp and asked if I was comfortable using ChatGPT or another AI to “cheat” in interviews involving languages outside of my professional experience, such as Java or Go.

(If this recap here looks weird, I’m largely just dictating the police affidavit that I wrote. Feel free to do an open records request with East Texas A&M University re Incident #251209012A for more details.)

Since Then

...I have been assigned interviews by my handlers at 12 different companies: Here’s a copy of the latest Google Spreadsheet revision.

* I warned Kevin Cambell with Yahoo. He seemed to have a hard time getting out of the interviewer mindset. I will always remember, after I told him a short summary of my story, his reply of “It sounds like you really don’t want the role...”. No shit, Kevin.

* I warned Monica Oswal with Xero. She got it. I actually think she already knew there was something wrong with the application.

* I warned Collin Allison with Tractian. Blew his fucking mind, but he assured me that he had seen bait & switch tactics like this before with H1B’s & would be sure to improve his recruiting strategy accordingly. I sure hope so as Tractian looks like they are working on some bleeding edge tech.

* I warned Sheila MacLean with SysDig. Blew her mind as well, which was kind of funny since SysDig is all about Cybersecurity. But she & SysDig handled it well, with Stefan Reicheneder, their head of Security & Compliance reaching out himself to request further information.

* I warned Kaitlin Pham who was recruiting for Carrum Health. Blew her mind also, but she asked for all the details & handled it like a real pro. If Boulevard Recruiting has more like her, then I know who I would want handling my company’s recruiting for remote jobs.

* I warned James Klein with EscrowSafe. He handled it well & later told me through LinkedIn that he had alerted his entire team, who couldn’t believe that I would do such a public service without getting something out of it. I told James that I did everything for this awesome blog post. It is awesome, right? 🥺

* Hannah Xu with ITC canceled our interview before it even began. I’m curious if there was any particular type of red flag that caught her attention.

* I tried warning Avery, ITC’s AI interviewer. Not sure if I succeeded, because I played most of the interview straight (never hurts to get free practice, right?)

* I warned Shaoyen Chang & Manoj Chavali of Synchrony. Chang said that he had noticed one yellow flag, which was that the fake resume seemed really heavy for the particular role that they were trying to fill. One of the shortest technical interviews I’ve ever had.

* I warned Ryan Kolatalo with Dick’s Sporting Goods. He was a good sport (sorry 😅) and offered me the role any way, but it was focused on Database Administration with SQL Oracle, so a bit outside my comfort zone (I’m pretty comfortable with basic SQLite3 & Postgresql features, although RubyOnRails’ ORM usually makes it so I don’t have to consider which relational database I’m actually using).

* I warned Samrat Jeyaprakash, Marcela Colimodio, Tania Aguirre, and Marco Cornejo of Tram Case through LinkedIn’s Sale Navigator after Samrat, Tram Case’s CTO, skipped out on an interview we were supposed to have. Not that an interview with a CTO is that big a deal when Tram Case only has 8 or so employees, but I was still looking forward to saying I warned a member of the C-suite in-person. Maybe next time 🥲

* I warned Todd Janss with Aha!. Aha! seems like a really awesome company for someone like me, just bursting with manic ideas, so I’m really glad that Todd took my report seriously and said that he would keep an eye out for the scammer signals that I mention in the recommendations section below.

* I warned Elaine Chai with Temu. This interview was a bit of a surprise to me until Elaine explained that Temu is expanding out of China into the U.S. & Ireland for data sovereignty reasons.

* I warned Hanna Niapas with Groq. She handled the situation well & demanded I let her know as soon as my blog post was published!

* I warned Kyle Brazeau with SafelyYou. This interview didn’t go too well for me because Kyle already had his guard up. Seems like he had already identified some flags within the resume itself. Kyle, I hope this blog post provides a better explanation than I did through Google Meet. 😅

* I warned John Samuelson with his stealth startup. He was pretty surprised, but he handled it well. Finally got my C-suite interview! 😎

* I warned Anna (Burns) Ciell with Zus Health. She welcomed the information I provided her, saying that it helped explain certain patterns that she had been seeing in recent applicants. More details in the recommendations section below!

I’ll update with more interviews for as long as these scammers let me interview for them. It’s not looking good for me, however, as my handlers have noted that none of the companies I’ve interviewed with have provided them with a positive update. 😅

In addition to interviews, these scammers have also said that they are sending me a fake I.D. so I can perform drug screens for background checks. They have also asked me to embellish my UpWork & LinkedIn profiles (They apparently have better luck with UpWork than LinkedIn right now, to no one’s surprise). And finally, they have asked me to create a LLC bank account so that I can send or receive funds through Relay.

Links to actual fake LinkedIn Profiles

Here’s every LinkedIn profile url from the fake resumes I was given:

• https://www.linkedin.com/in/andrew-johnson-b277a955/

• https://www.linkedin.com/in/ben-roble/ last name on resume is robles, however.

• https://www.linkedin.com/in/benjamin-weston-9166a374

• https://linkedin.com/in/joey-scales-b04a89ab

• https://www.linkedin.com/in/michael-nevels-6b97b175

• https://www.linkedin.com/in/alexander-howard-18a969138/

• https://www.linkedin.com/in/mattodevs/ (Matthew Owens)

• https://linkedin.com/in/toby-shepherd-463a6570

• https://linkedin.com/in/renaldopierrelouis

Recommendations

* A strong signal that will be short-lived is that a scam artists are generally using LinkedIn profiles that have no profile picture. Scammers avoid profile pictures because they don’t want to have to update the picture whenever changing proxies (LinkedIn: y’all need to enable users to see how often a profile picture changes.)

* Also lack of LinkedIn recommendations by real people or only having recommendations that don’t talk about having face-to-face, in-person communication is another red flag. In fact, Anna Ciell points out that this discrepancy applies to anything that requires time to build: scam profiles are unlikely to have many LinkedIn connections or a github account that has any real activity.

* The names of the LinkedIn profiles are generally reused because they are connected to actual people in order to pass background checks. Therefore, any LinkedIn profile that doesn’t have a unique name or has numbers in their URL gets a yellow flag, especially if some of the other LinkedIn profiles with similar names look sus.

* A valuable safeguard would be requiring every candidate to send a message from their LinkedIn profile to you during the intro interview (or, better yet, to call you by phone while on video), because I assume that other interview proxies do not currently have access to the email, phone, or LinkedIn profiles listed on the resumes, as our handlers control all forms of communication with the companies outside of the interviews themselves.

* Scam artists will adapt to every single safeguard you create, so please assume that each of my suggestions has a relatively short shelf-life. LinkedIn recommendations from real people talking about in-person interaction is by far the most secure, yet rarest green flag.

* Scam artists build their resumes specifically for automated screening systems. Maybe it’s time that we start focusing on the resumes that get filtered out instead? You know, like how a chess grandmaster will sometimes start with a suboptimal opening move to throw off their opponent because the optimal opening moves have been analyzed to death.

* According to my handlers: “Actually, you don’t need to talk based on resume. Resume is just resume for scheduling more interviews. In the interviews, you must pretend to have all experience with all requirements to pass the interview. This is the point.” So... maybe try asking about a framework or library that doesn’t exist? Idk. I got this coaching 14 interviews in so it might not be very relevant. 😂

* With the way that the job market is right now, if you have any doubt, throw the application out!

Sequel Hook

Actually, the fake I.D. has already been delivered to my house. I’ll provide more details on that once the Secret Service concludes their investigation.

I think I can get away with saying that if you work for Coinbase HR & you have a job applicant, likely for senior software engineer, named “Ben Ray Robles Gomez” who is having trouble scheduling their drug screening, then you need to take a second look at everything about their application.

Also, I recently made contact with someone who says that they have been harassed by the Lazarus Group, so, depending on how credible his report seems, I might write up an article on that.

Finally

If you made it all the way to the bottom of my article, then you’re obviously starving for unique content, so please check out the rest of my blog & subscribe for future thought-provoking articles, such as my attempt to trigger a marxist revolution in a global, remote-focused dev shop (The Russians didn’t like the idea. Lenin must be rolling in his grave right now.)

As always, let me know your thoughts!

I hope to hear from you soon!

What they don’t do well is provide deterministic results, learn beyond their training data, compile comprehensive solutions, or ensure exhaustive attention to detail (but I repeat myself).

Here’s the basic, structural reasons why:

* no deterministic results: LLMs depend on statistics combined with random number generation, otherwise known as temperature, to do their job. You can reduce the temperature, but removing it completely results in undefined behavior. Basically, randomness is part of what LLMs naturally are.

* no novelty: LLMs require processing training data to develop the statistical weights that I mentioned above. While there has been some progress made towards modifying weights based on receiving new information & use of external, dynamic memory, LLM’s basic architecture relies on known information compiled some time in the past.

* no exhaustive attention to detail: there’s a number of reasons for this. First & foremost, there’s the LM’s attention transformer, otherwise known as the SoftMax function. This function was originally developed to parse sentences for significance, which realistically meant dropping terms that didn’t matter that much so that more attention could be applied to the terms that mattered more. When applied to large context windows, this function might ignore entire sentences or even whole paragraphs. Worse, it does so non-deterministically, which means that you never know how a LLM might misinterpret the commands you gave it.

Don’t take my word for it. I’ve given AI itself the opportunity to confess its sins. If that doesn’t interest you, feel free to skip down to the solutions I offer at the bottom of the post.

Conversation with Gemini 3 Preview

## User

What are the structural weaknesses of large language models in the context of software development?

## Gemini 3 Preview

Large Language Models (LLMs) have revolutionized coding assistance, but they possess inherent **structural weaknesses** that create friction when applied to the deterministic, logical, and highly interconnected nature of software engineering.

Here is an analysis of the structural weaknesses of LLMs in the context of software development, categorized by their architectural and operational limitations.

---

### 1. Probabilistic vs. Deterministic Nature

The most fundamental mismatch is that software is deterministic (Input A must result in Output B), while LLMs are probabilistic (Input A leads to a statistical likelihood of Output B).

* **The Hallucination Problem:** LLMs generate code based on statistical plausibility, not logical verification. They often invent libraries, methods, or syntax that *look* correct (following the pattern of the language) but do not exist.

* **Subtle Logic Errors:** An LLM might generate code that runs without syntax errors but fails on edge cases. Because the model prioritizes the “most likely” next token, it often defaults to the “happy path,” ignoring boundary conditions, null checks, or error handling.

* **Inconsistency:** Asking the same question twice can yield different code snippets. This lack of reproducibility makes it difficult to rely on LLMs for rigorous system design or standardizing coding practices.

### 2. The Context Window Constraint

LLMs operate within a finite “context window” (the amount of text they can process at once). While these windows are growing, they are not infinite.

* **Fragmentation of Logic:** Large software systems rely on the interaction of thousands of files. An LLM usually cannot “see” the entire codebase simultaneously. It lacks the global context required to understand how a change in `Module A` might implicitly break `Module Z` via a circular dependency or a database schema change.

* **”Lost in the Middle” Phenomenon:** Even within a large context window, attention mechanisms tend to focus on the beginning and end of the prompt. Critical constraints buried in the middle of a large documentation file or code dump are often ignored.

* **Dependency Blindness:** The model may suggest code using a library version from its training data (e.g., Python 3.7 patterns) that is incompatible with the project’s actual environment (e.g., Python 3.12), causing “dependency hell.”

### 3. Lack of a Mental Model (World Simulator)

LLMs process syntax and semantics, but they do not possess a runtime environment or a “mental model” of state changes.

* **Inability to “Execute” Code:** An LLM does not run the code it writes. It cannot mentally trace a variable’s state through a complex loop or across asynchronous calls. Consequently, it struggles with **concurrency, race conditions, and memory management**, often suggesting code that is syntactically valid but functionally broken under load.

* **Spatial and Temporal Reasoning:** Software architecture requires planning for the future (scalability) and understanding spatial relationships (data flow). LLMs are generally reactive (predicting the next word) rather than planning-oriented, making them poor at high-level architectural design.

### 4. Training Data Limitations (Temporal & Qualitative)

The model is only as good as the data it was trained on, leading to specific structural weaknesses in code generation.

* **The “Knowledge Cutoff”:** Software moves faster than model training cycles. An LLM may not know about the release of a new framework (e.g., the latest Next.js features or a breaking change in AWS SDKs), leading it to suggest deprecated or insecure patterns.

* **Regression to the Mean (Mediocrity):** LLMs are trained on the entirety of the public internet (GitHub, StackOverflow). This includes high-quality code, but also a massive amount of bad, insecure, or inefficient code. The model tends to converge on “average” solutions rather than “optimal” ones, propagating anti-patterns.

* **Security Vulnerability Propagation:** If a significant portion of training data contains SQL injection vulnerabilities or hardcoded credentials (which is common in amateur code), the LLM may reproduce these security flaws.

### 5. Blindness to Non-Functional Requirements

Software development is not just about writing code that compiles; it is about maintainability, performance, and security.

* **Lack of Intentionality:** LLMs generate code to solve the immediate prompt. They do not consider long-term maintainability, code bloat, or “DRY” (Don’t Repeat Yourself) principles unless explicitly instructed. This can lead to a codebase filled with “boilerplate” code that is hard to refactor later.

* **Performance Ignorance:** An LLM might suggest a recursive solution that is mathematically elegant but causes a Stack Overflow error in production, or a database query that is essentially an $O(n^2)$ operation, because it doesn’t “understand” the scale at which the software will run.

### 6. The “Package Hallucination” (Supply Chain Risk)

A specific and dangerous structural weakness is **Software Supply Chain Hallucination**.

* When asked to solve a specific problem, an LLM may hallucinate a package name that *sounds* real (e.g., `pip install pytorch-audio-processing-helper`).

* Attackers have begun registering these hallucinated package names on repositories like PyPI and npm, injecting malware. When a developer copies the LLM’s suggestion blindly, they compromise their system.

### Summary

In short, the structural weakness of LLMs in software development is that they operate on **syntax and statistical correlation**, whereas software development requires **semantics, logic, and state management**. They are powerful engines for boilerplate and syntax translation, but fragile engines for logic and architecture.

Solutions

I don’t have solutions for all of LLMs’ structural weaknesses, but I do think that I’ve got a solid lead on solutions for a couple pain points:

* For exhaustive search & modify, try having your favorite LLM create a regex.

* For processing novel situations with deterministic results, I offer a novel executive function / belief system proof-of-concept that I intend to test against ARC-AGI-2’s public evaluation set, starting with all the puzzles that have yet to be solved by any LLM.

* For attention to detail, I offer a relevance index concept that I thought would be best tested with OpenCode or Anthropic’s Claude.

I’m looking for feedback, questions, technical critiques, & collaboration.

As always, let me know your thoughts!

I hope to hear from you soon!

A little over a week ago I was crossing town on a bicycle and I received a traffic citation for running a stop light and a warning for bicycling on the left side of the road.

The stop light that I was charged with running was on a separated two-way highway. Identifying gaps in traffic there is easy, so I see little reason to inconvenience multiple drivers just to reduce my legal liability.

Similarly, bicycling on the left side of the road enables me to easily see & react to oncoming traffic. I was pulled over in a parking lot because I identified oncoming traffic from both front & behind & I decided to minimize my risks by getting off the road.

The law enforcement officer made the argument that, even if bicycling on the left was safer, I was still in the wrong because breaking the law made me legally liable. I’d rather be legally liable and not get into an avoidable collision than have a distracted driver run up on me from behind!

Also, using a consequence of breaking a specific law as justification for enforcing said law seems like oddly circular reasoning. It also reminds me of the rumors I read about how walking in the street was criminalized following lobbying by the motor vehicle industry to reduce the legal liability of drivers in the early 1900’s.

My argument is that bicyclists should be prosecuted for reckless endangerment or public nuisance, if they are indeed doing or being such. Maybe even for failure to wear appropriate safety equipment or failure to signal (I’d have to plead the 5th if anyone asked about this, but for some reason, neither of these issues are listed on my citation, even though these issues are the ones most likely to affect my safety)... But laws against specific actions, such as running stop lights and requiring bicyclists to ride on the right side of the road are unnecessary and may even be harmful.

Anyway, as always, let me know your thoughts!

I hope to hear from you soon!