MeshCore development team splits over trademark dispute and AI-generated code

Project governance, trademarks, and monetization

  • Big concern over one team member secretly registering the MeshCore trademark and trying to control ecosystem components (apps, tools, standalone devices).
  • Many see this as a classic “cash out / power grab” once a project gains >100k users and wide repeater deployment.
  • Some argue it’s reasonable for a marketing/third‑party actor to seek a trademark to profit from add‑ons; others compare it to trademarking “Apple” after writing an app and call it hostile.
  • Comparisons to Meshtastic and other radio projects: some say strong trademarks are necessary for interoperability and reputation; others find enforcement “draconian” and culturally at odds with open source norms.

Closed vs open source components

  • Firmware and radio protocol are widely described as open source (MIT), but official mobile app and MeshOS are closed.
  • This closed core UX is a deal‑breaker for a number of commenters; several immediately lose interest on learning the client is proprietary.
  • Others are fine with a monetized, closed client as long as the protocol and firmware remain open, citing alternative open clients and web-based tools that already exist.

AI‑generated / “vibe coded” software

  • Strong split: some insist AI use must be clearly disclosed, especially in safety‑relevant comms software and when licensing under a project’s terms.
  • Concerns include: plausible‑but‑wrong code, overwhelmed reviewers, hidden security issues, and contributors without real understanding of generated code.
  • Others argue AI use should be judged on actual code quality and tests, not on principle, and see the “anti‑AI” framing as a distraction from the trademark dispute.

Code quality, testing, and legality

  • Criticism that MeshCore lacks automated tests, has weak validation (e.g., accepts invalid GPS coordinates), and maintains many open PRs/issues while rejecting test contributions.
  • Allegation that recommended US LoRa settings are illegal under FCC rules; maintainers are said to have ignored detailed reports. Some hams in the thread stress that spectrum rules are not optional.

Use cases, culture, and alternatives

  • Several see LoRa mesh hype as overblown for “SHTF” scenarios; real reliability is limited and setup is non‑trivial, though it works well for games, hiking, and sensor networks.
  • Cultural friction between ham radio operators and “radio hackers” / mesh enthusiasts is a recurring theme, with accusations both of gatekeeping hams and ham‑bashing mesh communities.
  • Alternatives discussed: Meshtastic, Reticulum, LoRaWAN, and Wi‑Fi HaLow; each is criticized for either immature tooling, proprietary stacks, or fragile codebases.