Consider Open Sourcing FireControl and BendControl

1

This came from a reply, Fiber Laser for us Hobby Guys? - #44 by holla2040

Open source isn’t about “free software.” It’s about unlocking a force multiplier.

We have a variety of machines in our shop, and overall my Pro has been solid for years: it holds tolerances, starts fast, is easy to clean, and requires near-zero operator training. My biggest frustration is simply the lack of FireControl and BendControl releases.

By day, I’m an embedded hardware/firmware engineer. For context, here are my stats for the last 2 days:

Lines Changed (Last 2 Days)

  • Files changed: 121

  • Insertions: +6,067

  • Deletions: -3,465

  • Net change: +2,602

I’m using leading-edge agentic tooling and typically make 10+ repository commits per day. I’ve also been coding since 1978 — almost 50 years — so I’ve watched development models evolve a lot over time.

At this point, Langmuir should seriously consider open-sourcing FireControl and BendControl, and allowing the community to contribute improvements, enhancements, and bug fixes. Langmuir could still control the official release process by managing pull requests, while also allowing advanced users to run their own forks when needed.

Yes, this is a big step for Langmuir, and I understand the safety/liability implications. But those issues can be addressed with licensing, disclaimers, gated builds, and clear separation between “community builds” and official validated releases. Done properly, it would allow Langmuir to focus on design and manufacturing of new products, while the community helps maintain and improve legacy software.

Linux was open-sourced 35 years ago, and the result speaks for itself: billions of deployments, powering much of the internet and all Android devices, supported by a massive developer community. I’m not claiming FireControl/BendControl is Linux — but the open development model clearly works when managed well.

August 25 1991

image

image504×356 35.5 KB

6 Likes
2

I want to frame this as a competitive advantage, not just a “nice-to-have” feature request.

A strong example is Orca Slicer in the 3D printing world. It’s history stems from Bambu Studio, a fork of PrusaSlicer, itself a descendant of the original Slic3r, evolving into a powerful, community-driven tool.

Orca didn’t win because it had the biggest company behind it — it won because open development unlocked speed, quality, and ecosystem scale. The community iterated faster than any closed team could, fixed bugs in days instead of months, and added features driven by real operators doing real work.

That matters because software is now the differentiator in hardware businesses.

In hardware ecosystems like CNC / plasma / sheet metal automation (just like 3D printing), the long-term winners tend to be the platforms that:

  • evolve quickly

  • support more workflows and edge cases

  • build trust and goodwill with operators

  • remain maintainable over years, not just product cycles

Open-sourcing FireControl/BendControl could move Langmuir into that “platform” position.

Why open source is a competitive weapon here

Closed development has a hard ceiling: your internal team can only test so many environments, fix so many bugs, and build so many features. Meanwhile your customers are encountering issues every day — network weirdness, controller edge cases, torch height quirks, table-specific behaviors, workflow gaps, integration requests, etc.

Open source flips that dynamic:

  • Bugs don’t just get reported — they get fixed and submitted as PRs

  • Features don’t just get requested — they get implemented by power users

  • Software stops being a bottleneck — it becomes a force multiplier

Langmuir still controls the official direction and releases, but you gain a “parallel engineering organization” made up of your most invested customers.

The business outcomes are real

This isn’t theoretical. The Orca Slicer model shows what happens:

  • Faster iteration = higher customer satisfaction

  • More capability = more “reasons to buy” and fewer reasons to churn

  • Community innovation = differentiation competitors can’t easily replicate

  • Trust = more repeat buyers, stronger brand, more word-of-mouth

And importantly: open-sourcing also helps Langmuir reduce long-term support burden because community fixes and documentation scale better than ticket-driven development.

“But safety/liability…”

Totally valid concern. But it’s solvable, and many companies already solve it using:

  • separation of official validated releases vs community builds

  • signed binaries for official releases

  • gating high-risk settings behind warnings/permissions

  • clear support policy: Langmuir supports official builds only

  • licensing and disclaimers

This is not “giving up control.” It’s choosing a model where Langmuir wins faster.

Bottom line

If Langmuir open-sourced FireControl/BendControl and ran it the right way (public repo + PR workflow + official releases), I think it would become one of the most important differentiators in the market.

Competitors can copy hardware features.
They can’t easily copy a thriving software ecosystem and developer community.

That’s the advantage.

3 Likes
3

Another open-source success story that’s directly relevant here is Git.

Git wasn’t created by a giant corporation. Linus Torvalds wrote it in 2005 because existing tools couldn’t keep up with the scale and pace of Linux development. The important part isn’t the origin story — it’s what Git proved:

If you build the right collaboration model, you can scale development far beyond what any single company can do.

Git became the foundation of modern software development for a reason:

  • distributed workflow (forks are normal)

  • strong traceability (blame, history, review)

  • clean contribution process (PRs, code review)

  • separation between official releases and experimental branches

That model is exactly what Langmuir could use for FireControl/BendControl.

Why Git matters for Langmuir

Langmuir software is running in real shops, on real machines, under real constraints. That creates constant “edge case pressure”:

  • different tables and setups

  • different workflows

  • different operators

  • integration needs

  • reliability + safety requirements

A closed-only workflow forces every single improvement through one bottleneck: internal engineering bandwidth.

But Git’s whole contribution model was built to remove that bottleneck while still keeping control:

  • Langmuir remains the maintainer

  • Langmuir controls what gets merged

  • Langmuir signs/releases the official binaries

  • community members can submit PRs for fixes/features

  • advanced users can run forks if needed (at their own risk)

This is precisely how large, high-quality codebases stay healthy for decades.

Open source doesn’t reduce quality — it can increase it

Git also destroyed one of the biggest myths in software: that open source is chaotic.

In reality, mature open source can be more disciplined than closed development because:

  • changes are reviewable

  • every change is tracked

  • regressions are visible

  • issues are documented publicly

  • many engineers can audit code paths

When you have safety and reliability concerns, that transparency can actually improve trust, because users can see that problems aren’t ignored and fixes aren’t mysterious.

Competitive advantage again

Langmuir’s advantage isn’t just “good machines.”
It’s “good machines + software that improves continuously.”

If Langmuir embraces a Git-style open development workflow, it makes the software:

  • harder for competitors to match

  • faster to improve than any closed team alone

  • more resilient long-term

  • more trusted by technical customers

Hardware gets copied.
A living ecosystem built around your software is much harder to copy.

Git is the blueprint for how to do this while keeping quality and control.

Git didn’t really “take over the world” until GitHub made it easy and social: issues, pull requests, code review, forking, and discovery. GitHub turned open source from “download patches from random places” into a scalable workflow where anyone can contribute safely and transparently.

GitHub was founded in 2007/2008 by Tom Preston-Werner, Chris Wanstrath, PJ Hyett, and Scott Chacon . Microsoft acquired GitHub in 2018 for $7.5 billion (all-stock deal) — which says a lot about how strategically valuable the open-source ecosystem became.

Where scale matters: GitHub has ~630 million total repositories as of 2025 (per GitHub’s Octoverse), and it reports that ~63% of all repositories are open source or public — implying on the order of ~400 million open/public repos on the platform today.

1 Like
4

A great example of a company taking a real “control vs velocity” risk is Facebook with Cassandra.

Cassandra started as an internal Facebook project. It was core infrastructure — not some side utility. It handled real data at real scale. In other words: it was exactly the kind of software most companies would keep locked down and proprietary because it’s mission-critical.

But Facebook made the opposite call.

They took the risk of giving up tight control and open-sourced Cassandra.

That decision is worth paying attention to because it wasn’t just an engineering move — it was a strategic bet:

“If we open this up, the combined force of a global community will improve it faster and better than we can alone.”

And that’s exactly what happened.

Once Cassandra went open, Facebook essentially gained a force multiplier:

  • far more testers

  • far more environments

  • far more edge cases discovered quickly

  • far more performance improvements contributed

  • far more bug fixes arriving without Facebook having to fund all of it internally

Open source didn’t weaken Cassandra — it strengthened it. It made it more reliable and more capable because the code was being exercised everywhere.

Yes, that meant Facebook gave up some control. People could fork it. People could build variants. Development direction wasn’t 100% “inside the building” anymore.

But Facebook retained the part that mattered:

  • they still guided the core direction

  • they still benefited from upstream improvements

  • they gained credibility and community trust

  • and they turned a closed internal cost center into a shared innovation engine

This is exactly the lens I think Langmuir should look through for FireControl/BendControl.

Right now, closed development keeps control tight — but it also caps the rate of improvement. If releases slow down, features and fixes pile up, and frustration grows, that becomes a competitive weakness.

Open-sourcing is absolutely a risk — but it’s also how you unlock a multiplier:

  • customers become contributors

  • bug fixes arrive as PRs, not just complaints

  • power users build features Langmuir would never have time to prioritize

  • legacy software gets maintained without dragging down new product development

Cassandra is proof that sometimes the winning strategy is:
give up a bit of tight control to gain a 10x improvement engine.

Langmuir could still control “official” validated releases — but opening the code would turn the community into leverage instead of pressure.

3 Likes
5

If someone thinks open-sourcing FireControl/BendControl is “too risky” because it gives up tight control, it’s worth looking at what happened when major companies made that exact bet.

In multiple industries, releasing the code didn’t weaken the company — it changed the entire ecosystem and accelerated adoption so much that it reshaped markets.

Examples of “give up control → change the industry”

  • Google → Kubernetes
    What it is: software that coordinates and runs large fleets of computers automatically.
    Impact: This became the default foundation for modern cloud computing. By open-sourcing it (and handing governance to a neutral foundation), Google helped standardize how the internet is operated — and the whole cloud industry moved faster as a result.

  • Meta (Facebook) → PyTorch
    What it is: a core software framework for machine learning and AI.
    Impact: By releasing it, Meta helped accelerate AI research and deployment globally. Thousands of engineers improved it, universities taught it, companies adopted it, and it became a major part of today’s AI boom — far beyond what one company could have built alone.

  • Microsoft → VS Code + TypeScript + .NET
    What it is: developer tools used to write modern software.
    Impact: Open-sourcing these helped Microsoft regain developer trust and influence. VS Code became the most widely used programming editor. TypeScript reshaped web development by making JavaScript more reliable. In practical terms: open source changed how software is written across the industry.

  • Google → Android (AOSP)
    What it is: a phone operating system platform.
    Impact: Google opened Android knowing competitors could fork it — and it still became the dominant mobile platform with billions of devices. This created an entire industry ecosystem (manufacturers, apps, accessories, services) and massively expanded mobile computing worldwide.

  • AWS → Firecracker
    What it is: foundational virtualization software used to safely run workloads in the cloud.
    Impact: By releasing it, AWS increased trust and adoption, improved security through broader review, and influenced how high-density cloud infrastructure is built. This kind of code runs parts of the modern internet at scale.

  • Arduino → open hardware + open software
    What it is: an open-source microcontroller platform (hardware designs + software tools).
    Impact: Arduino basically created the modern “maker” ecosystem and lowered the barrier to embedded electronics. Because it was open, it exploded into classrooms, hobbyist shops, labs, product prototypes, and entire businesses. Countless add-ons, libraries, shields, and compatible boards were created by the community. Arduino didn’t just ship boards — it shipped a platform, and the platform became the standard entry point for physical computing.

  • Raspberry Pi → open ecosystem + accessible Linux computing
    What it is: a low-cost Linux computer platform built around open software and a community-first ecosystem.
    Impact: Raspberry Pi transformed education and embedded computing worldwide. Because it embraced open Linux tooling and encouraged community development, it spread into schools, robotics, home automation, labs, industrial control, and product prototypes. The ecosystem built around it is enormous: thousands of libraries, tutorials, add-ons (“HATs”), and community-supported distributions. Raspberry Pi created a standard platform for physical computing.

The pattern is the point

All of these companies knowingly took the same risk:

“We’ll give up some tight control so the community can scale improvement beyond our internal bandwidth.”

Open source isn’t about “free software.” It’s about unlocking a force multiplier:

  • bugs don’t just get reported — they get fixed

  • edge cases don’t just get complained about — they get solved

  • development doesn’t bottleneck inside one company — it scales with your user base

Langmuir could keep control where it matters: official validated releases (signed builds, QA, support boundary), while still enabling community contributions and optional forks.

Competitors can copy a torch mount or gantry design.
A healthy software ecosystem is what creates long-term advantage.

4 Likes
6

This looks like Grok formatting :slight_smile:

I 100% agree though. Would help the community immensely and heck, make a “rewards” program for those that contribute to fixing / adding features.

1 Like
7

chatGPT helped writing these posts.

1 Like
8

I think would work better to allow a “Plug in” system. That way they could expose an object com port to the app and they would “be in control” of the base machine/windows app. Or…………. IF they would allow an iron clad NDA from us peeps that poke the stack then sure do true “controlled” access open source.

2 Likes
9

I’m inclined agree with Craig and his buddy ‘chat’. Just today I provided a modified SheetCam post processor to a fellow member and thought, the Langmuir PP SHOULD be in a repository on GitHub so we can all add our GeeWhiz and LS still has control over the ‘release’ version of it, but the ‘crew’ could add AND SHARE their own swizzles. The only reason I could modify the original PP is that SheetCam’s PPs are raw text files and THEY have documented the internal functions.

Same is true on the UI and all the other nonsense that LS thinks is ‘family jewels’.

2 Likes