MeshCore development team splits over trademark dispute and AI-generated code
A split in the MeshCore off‑grid mesh networking project has exposed tensions over trademarks, closed‑source components, and heavy use of AI‑generated “vibe coded” software in critical tools. Commenters debate whether AI‑written code can be trusted without strong testing and transparency, criticize attempts to quietly trademark the MeshCore name for commercial gain, and contrast MeshCore’s governance and culture with other radio, mesh, and open source projects. Many see the core LoRa firmware as technically promising but worry that legal maneuvering, weak code quality practices, and fragmented ecosystems could undermine long‑term trust and adoption.
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.