For over two decades, the TI-84+ CE and its predecessors have served not only as tools for test-taking and classroom learning, but also as gateways into programming, low-level systems development, and applied mathematics for thousands of students and hobbyists around the world. Through community-led initiatives, students have created a wide array of "cool things" — from games, to math and science utilities, to shells, and even full alternative operating systems. The possibilities have felt limitless.

Community-driven platforms such as Cemetech, CodeWalrus, TI-Planet, and Omnimaga have hosted programming contests, presented at Maker Faire in Flushing, NY, and consistently pushed the boundaries of what these devices can achieve. For many, this early experience became the foundation for careers in computer science, engineering, cybersecurity, and related fields.

That changed when support for assembly and C programs was removed in newer operating system versions. We recognize that this decision was made in response to concerns about exam security — a priority we share and fully respect. However, in seeking to prevent potential misuse, this change also erased years of legitimate educational value, innovation, and exploration and eliminated a creative ecosystem that fostered interest in STEM for countless students.

This letter is not a protest — it is merely a testament and an appeal for greater partnership between Texas Instruments and the independent development community. We are aware that TI maintains dialogue with certain community leaders behind the scenes, and we value those efforts. Yet to most developers and students, those conversations are invisible, leaving the impression that TI is at best indifferent and at worst hostile. More open, collaborative communication would build trust and help prevent the cycle of misunderstanding and overreaction that has harmed both TI and its users.

A common question is: why push for Assembly and C when Python is already available? The answer is that they serve fundamentally different purposes. Python is an excellent introductory language and widely used in web, data, and server applications — but it is not suited for embedded systems, where precise control and efficiency under strict resource limits are essential.

Assembly and C provide that control. They also teach a critical lesson: optimization matters. On the TI-84+ CE, developers learn to make every instruction count, manage memory carefully, and design algorithms that run efficiently on limited hardware. These lessons translate directly into better programming practices on modern platforms, producing developers who write code that is not only functional but also scalable and resource-conscious.

Just as important, the challenge itself is part of the value. Figuring out how to achieve complex results within tight constraints is what drives the community. The lack of features like user interrupts, for instance, has pushed developers to create event-driven systems for USB, storage, input, and networking that nearly emulate interrupt behavior — an innovation born entirely from working within limitations.

In short, Assembly and C are not about games versus exams. They provide an irreplaceable, hands-on way to understand how computers truly work, to practice problem-solving under constraints, and to experience the satisfaction of overcoming them on a device that is often the first programmable tool that students truly "own". Removing this path cuts off one of the most effective and inspiring entry points into STEM.

Over the past several years, a damaging cycle has emerged. Each time a sensationalized video or social media post stokes exam-security fears — often around exploits that were already patched, based on hardware tampering, or malicious intent on the part of lone actors — exam boards pressure Texas Instruments to "do something". TI, in turn, responds with sweeping restrictions that strip away legitimate programming capabilities, punishing the very developers who were not responsible in the first place. The result has been a cold war: the community forced to hunt for new exploits just to keep doing what it has always done in good faith, and TI locked into a reactive stance that alienates loyal users while failing to address the real threats.

I speak to you now as not just an independent calculator software developer but as a person who knows a thing or two about cybersecurity and incident response: Companies that develop software will always face bureaucratic pressure from individuals who know little about security, yet demand visible action to assuage their own concerns. Too often, the actions they push for cause more problems than they solve — introducing new bugs, alienating users, and even inviting further attacks on infrastructure. True security means having the discipline to say "no" to pressure when the proposed action fixes nothing, to not take a sledgehammer to an issue that demands a scapel, and to defend the rigor of your investigation in the face of external pressure. For the sake of your company image, your consumers, and the broader educational community, I urge you to embrace this lesson quickly.

This cycle of cat-and-mouse benefits no one. It wastes TI's engineering resources, drives away talented students and hobbyists, and creates the false appearance of security while real bad actors — often operating outside the programming community entirely — continue unaffected. Worse, it pits TI against its strongest ally: a development community that has:

• Consistently promoted responsible use and discouraged cheating or the abuse of exploits to bypass legitimate protections (with the exception of those necessary for C/Assembly).
• Honored multiple gentleman's agreements, to the best extent possible, to prevent the release of further exploits in exchange for the continued ability to run Assembly/C via known exploits.
• Extensively tested your tools and reported critical issues — essentially providing free QA testing.
• Built forums that serve as an unofficial help center, where students and educators can get support without tying up your customer service lines.
• Provided software, tools, and development appeal that extends the usage of your calculators well beyond school years — creating some long-term customers you might not otherwise have.

While the development community has not always been blameless in the erosion of trust between us, it is difficult to police every channel for every malicious release or overzealous reverse-engineering that might occur. What matters is that the core community does the best it can: we moderate, we act against bad actors because we care for the product as much as you do, and we work to protect your interests alongside our own.

The ask here is not that you revert to the days when Assembly and C were freely available (though many in the community would welcome it), but that you temper the hyper-reactive stance to clickbait and lone-wolf actors. Take the time to discern whether an issue requires a scalpel rather than a sledgehammer, and engage the community with greater openness and transparency in the process. At minimum, this could mean designating a point of contact we all are aware of or being willing to participate publicly/officially in forum discussions when situations warrant it. We share the same interest in keeping your platform safe, and working with us — rather than against us — will always yield better outcomes.

We recognize that the calculator division of Texas Instruments is, first and foremost, an educational company, trying to balance three competing lines: serving students, serving educators, and serving developers — all while simply trying to deliver a calculator that does what it needs to do. Regulators and exam boards have, unfairly, shifted onto TI the burden of preventing classroom misconduct — a responsibility that rightfully belongs to exam proctors. It is not your responsibility to play cryptographic 4D chess with customers so exam administrators don't have to do their jobs. And if, even with a secure exam mode, students still insist on cheating, perhaps the problem lies not with the calculator, but with how exams are supervised and conducted — or more broadly, with how students are motivated (or not motivated) to learn. Shifting that burden onto calculator manufacturers sidesteps the real issue, a deflection that has become increasingly common in bureaucracy and government these days.

Broad restrictions that affect an entire community of developers in response to isolated incidents risk diminishing the very creativity and goodwill that have long benefited your platform. A more collaborative relationship with the development community can ensure both exam integrity and the continued innovation that makes the TI-84+ CE a lasting educational tool.

In fact, an active partnership with the independent development community, if properly framed, could strengthen TI's standing before exam boards. Rather than being seen as a company under constant attack, TI could demonstrate that it collaborates with a network of (primarily open-source) ez80 developers, software engineers, and even security analysts who help test, identify, and responsibly report vulnerabilities. This would not only improve exam security but also highlight TI's leadership in turning a potential risk into an asset. Any reasonable exam board member would find it difficult to dismiss such an approach, especially given the long-established view that open-source development (and the associated collaboration) often produces some of the most transparent, resilient, and secure software available.