TicketsCAD v4 beta program — invitation and terms

[Eric Osterberg]

Thanks for your interest in helping shape TicketsCAD v4 ahead of its public release. This message outlines what the beta program asks of you, what you get in return, and the ground rules that keep the work safe for both of us. Read it through; if you're in, the registration form is at the end.

The short version: I'm building TicketsCAD v4 as an Apache 2.0 open-source CAD platform for volunteer fire, EMS, ARES/RACES, CERT, and small-agency dispatch — niches that commercial CAD vendors have largely abandoned. You'll get early access to a working but pre-release system; in return, you'll use it in a real (non-life-safety) scenario, tell me what works, what doesn't, and what's confusing.

Why this program exists: the gap between "code that runs in my lab" and "code that runs in a real agency's environment" is exactly where TicketsCAD lives or dies. The agencies who join the beta are the ones whose feedback will shape the public release.

---

Beta Tester Agreement

By registering for the beta program you agree to the following terms. These terms apply only during the beta period; once any specific file or feature lands in a public release under the Apache 2.0 license, the restrictions on that content fall away.

1. Confidentiality

• No public sharing of files, screenshots, UI captures, specs, or design docs from the repository without prior written approval.
• Restriction on a given piece of content automatically lifts when that content becomes part of a public release.
• You are responsible for keeping your local copy reasonably secured. That means: apply vendor updates promptly to your operating system and supporting infrastructure, and use a secure configuration (no public-internet exposure without authentication, no default credentials, TLS for all administrative access).
• TicketsCAD updates should be installed promptly — within roughly 36 hours of notification. Tracking the git repository is recommended; a git pull plus a php sql/run_migrations.php is usually all that's needed.

2. Use restrictions

• You acknowledge that TicketsCAD v4 is pre-release dispatch software and that you assume responsibility for all issues that arise from your use of it.
• The software may not be suitable for life-safety dispatch in its current state. Drills, exercises, training scenarios, and ARES/RACES practice nets are the intended beta use; actual emergency dispatch for life-safety situations is not.

3. Feedback obligations

• Commitment to actively use the software in a representative scenario — a drill, a planned exercise, a non-emergency operational scenario where you'd otherwise use a CAD system.
• File bug reports by email to ejost...@gmail.com (a structured issue tracker comes later in the program).
• Check in at least every 7 days with a brief status note covering what you've tested, what worked, and what needs improvement — positive feedback and constructive criticism are both useful.
• Flag specific UX confusion and documentation gaps as you encounter them; screenshots are strongly recommended.
• Surface anything in the install or admin flow that required external help to figure out. Those are the documentation holes worth filling before public release.

4. Open-source contribution framing

• TicketsCAD v4 will be released as Apache 2.0 open source upon public launch.
• By participating, you're helping shape an open-source contribution to volunteer fire, EMS, ARES/RACES, CERT, and small-agency dispatch — niches underserved by commercial CAD vendors.
• Any feedback, bug reports, suggestions, and documentation contributions you provide are licensed to the project for use without restriction.
• Optional code contributions follow the project's existing pattern: Apache 2.0, DCO sign-off on every commit, no AI co-author trailers.

5. Liability and no warranty

• Software is provided AS-IS, with no warranty of any kind, express or implied.
• No liability for data loss, downtime, missed dispatches, or any operational disruption arising from your use of the software.
• You run the software at your own risk.

6. Tester conduct

• No transferring access to other people — repository access is granted per-individual.
• No reverse-engineering, decompiling, or building a competing product from this code during the beta period. (The Apache 2.0 license will permit this freely after public release; the pre-release NDA window does not.)
• Good-faith testing only — no attempts to exploit the software for non-testing purposes.

7. Termination

• Either party may end the testing relationship at any time, for any reason, with no penalty.
• On termination: you stop using the software, delete local copies where practical, and return or destroy any documentation marked confidential or not yet publicly available.
• Surviving clauses after termination: confidentiality (until public release), liability disclaimer, and the feedback license assignment.

8. Branding

• You may say you're a beta tester for TicketsCAD.
• You may not claim endorsement, affiliation beyond that, or use the project name or logo in your own promotional materials without permission.
• Public mentions like "we use TicketsCAD for our drills" are fine; commercial use of the name is not.

9. Geographic and regulatory responsibility

• You are responsible for your own compliance with local laws around dispatch operations, radio communications, data retention, and personally-identifying-information (PII) handling in your jurisdiction.
• If you use the radio or communications integration features, you are responsible for your own FCC licensing (or your country's equivalent) and applicable on-air identification rules (§97.119 in the United States for amateur radio).

---

How to join

1. Register at https://training.ticketscad.com/beta-tester. The form takes a few minutes and asks for contact details, your agency, your expected scale, and your GitHub username for repository access.
2. You'll get a reply within 3 business days — either an invitation to the GitHub repository with installation instructions, or a note explaining why this round isn't the right fit (capacity, scope, or compatibility reasons).
3. First-week kickoff: install in a non-production environment, get a basic incident through the system, and send your first weekly check-in.

If you have questions before registering, reply to this email directly.

73, Eric Osterberg N0NKI TicketsCAD

PS: Most likely, invitations will be sent this afternoon. Two new videos have been posted a a few deleted videos have been restored after talking with youtube about their claims of PII violations.

Now available: instructions on how to update using GIT for both Windows and Linux.

[Arnie Shore]

All, I've looked at a lot of code in my time - hitting six decades -- and I just haven't seen the quality and completeness Eric is laying down here.  Not even in high-$ commercial stuff.  

And FREE!

As a volunteer!

C'mon guys ; help him out here!  Volunteer what you can do to help!

AS

--
You received this message because you are subscribed to the Google Groups "Open Source CAD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-source-c...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/open-source-cad/CAJLaYFW8Eh_SkNTtW8LmxKKc%2BAFQAshxD%2BfkBHgyFYAwcazSYA%40mail.gmail.com.

[Jeff Carrier]

I wouldn't mind testing V4 either.  I'd probably have to test it in an ARES capacity first but I'm also running tickets for my very small ambulance service.  

[Eric Osterberg]

That sounds great,

If you can submit the application right away, I'll try and get you included in today's first batch. I'm granting access to early adopters right now.

To view this discussion visit https://groups.google.com/d/msgid/open-source-cad/CAA_aZLhajyqJVJ%3DYnB2f2ux%2Brk%3D%3DmYx-586Gv5reXvatX1rs6g%40mail.gmail.com.

[Darren Deakin (UKDeek)]

My day job is working for a regional UK ambulance Trust in the emergency operations centre, and I use CAD software that costs a huge amount of money, and TicketsCAD gives a lot of the same dispatch functionality as that software, such as resource tracking, two-way data, road netting (nearest available resource to an incident), etc.

I will ALWAYS champion TicketsCAD and it is nice to see it is still being supported and being developed.

[Kurt H.]

Hello Eric

the new GUI looks great, thanks for your hard work!

 I have three questions for you:

- Are you planning to make the user interface language switchable? If so, I’d be happy to volunteer to translate it into German. Just send me a file with the English text, and I’ll provide you with the translations.

- I like the "Radio" implementation, but—we don't use DMR here. We use either TETRA or, mostly, old analog radios. For the analog radios, I'm planning to create a kind of "emergency repeater" connected via RoIP, so I'd really appreciate a RoIP feature... Would it be possible (with a switch) to use a Mumble client instead of the DMR client?

- is it still possible to use offline maps?

Thanks and best regards from Switzerland,

Kurt 

To view this discussion visit https://groups.google.com/d/msgid/open-source-cad/CAJLaYFUORgEDAXkqdufA_ZBqYPteQr94ciZdyjBTfV3pNHswWA%40mail.gmail.com.

[Eric Osterberg]

Hello Kurt.

I have thumbed this out on my mobile device so I apologize for any errors, some part of it was done as voice to text, so let's hope Google does the job correctly. 

German is already supported in a default installation. However, the translation was entirely done by AI, so I would love to hear your feedback and any changes you'd like to submit. 

I have a lot of ideas for the communications interfaces for voice within tickets CAD, but in an effort to get the software released, I've decided to table those until a future version. 

Most likely before the end of the year, but it's at least 60 days away. The earliest a beta would be seen would be 45 days. 

If you look within the source code,(when it's released), You can see some of the artifacts of the architecture I've been working on.

The voice communications platform itself has become almost as large if not larger than the entire tickets CAD system. 

I really like the audio interfaces from proper physical CAD systems I worked with in the '90s. 

I would like to have the ability to set the volume level for select and unselect audio paths, I want the ability to transmit simulcast on multiple modes by selecting more than one PTT to be active. I would like to support physical inputs for the PTT button, and still allow on-screen selection of individual channels for PTT. 

I would like to have the ability to create a patch bus, and be able to assign different channels to either input or output or both to a particular patch bus. There are incredible complexities to this architecture. Echo cancellation and audio delay are a couple examples. In incoming stream, arriving at near real time, will need to have a delay inserted before connecting to a digital mode which may need a moment for an accept tone or the network to come up. This audio would need to be buffered, and in the event that you receive a bonk, a wait, or a reject, the system would need to know what to do with that audio.

I have given serious consideration to creating a competitor to the Zello service as an add-on to the platform. Most likely the protocol used underlying the mobile app would be mumble-based.

For analog radio interfaces, I had designed some physical hardware which I hoped would be inexpensive and I could sell for a reasonable price. But through consultation with my AI teams, we've decided that it would be best to connect with existing hardware. To keep costs reasonable for amateur radio and volunteer use. Use, I've looked at the All-Star Network. This is the one that is based on The Asterisk voip platform. I do need to do some additional research and possibly support other roip platforms due to commercial restrictions. 

I have no experience with Tetra but would sure love to get my hands on the infrastructure and radios to give it a try. 

The platform currently supports Zello for work and the Zello personal platform. I know Zello for work offers radio interfaces, this might actually work for you today, You can create a free work demo account, but it has a limited lifespan before you need to subscribe to their plans. Here in the US I believe it's about $8 per subscriber. I don't know the rate for the ROIP interface but theoretically you may be able to get by with just two accounts. One for Tickets CAD and one for the radio interface.

Additional interface ideas for the communications platform include SIP for IP telephony, rstp for video feeds which can include audio, I had again looked into designing custom hardware which would be a intercom station, with a controllable output. The concept would be things like gate access, and having the ability to patch these into other modes based on availability or escalation was an idea in the architecture. Some examples might be a gate into a facility, where you want to ring. Operator or guard station but if they are way or fail to reply within a time frame, you could ring digital devices or ring analog devices and support entering a code to remotely release the output thereby unlocking the door.

There are other iot devices which are common in the US. I don't know if you have them there, for things like call for help buttons. In our large warehouse stores or department stores, you may find a button that you can press on the wall for assistance and this rings. Rings department manager who, if they do not answer immediately, would create an overhead page. You might hear something like assistance needed in the paint department on the overhead page.

Of course I have a lot of ideas here, so as you can imagine, this blossomed into something gigantic and impractical to include in this release now. 

As for mapping, the current best practice is to use an online map but enable caching. The caching service is built into tickets CAD right now. What this changes is that all clients of the web app point their queries directly to Tickets, CAD, and Tickets. CAD will serve a map tile from its cache, but if the cache is not available it fetches from the map source. This provides for high availability to the maps provided that you have loaded that map tile in the previous 90 days. Many map providers have been dealing with apps designed to siphon down all of their maps for offline use, and they take a heavy server load when people are downloading every map they think they might ever need, so all of them pretty much prohibit this practice now. 

You can define your own tile sources. And there are instructions on how you can stand up a tile server. I'm not sure if you're familiar with the term, but generally online map providers are rendering tiles, and the Web UI stitches the tiles together for your view of a map. So the term map server and tile server are nearly synonymous.

I have not used it yet, but a beta tester suggested there be an ability to stretch an image over the top of a map as a layer. 

This has been reported to be working and allows for things like taking the map of a fairground or a parade route and pinning it on top of a map. There are probably ways that you could also utilize this to be the actual map if you prefer. 

I hope to have tickets CAD exposed either as a public release, or a public beta within the coming week. We're at a code freeze now, and working on cleaning up some prior commits which contains sensitive or confidential information. Most likely we will create a clean repository and post the necessary files without the previous history. The holdup at the moment is trying to decide how future development would go forward if we have two repositories. 

I'll throw out here one more concern of mine. As the new tickets CAD is drawing attention, some of that attention is coming from commercial providers who feel threatened by the quality of what's being built here.. I have already experienced a couple of emails regarding possible patent infringement. There appear to be a lot of patents in this space.. I don't believe that all of the patents that have been issued are well deserved. The application of machine learning or AI or LLMs into a particular use seems to have received a patent. As I think about this, it's sort of like a knife and fork, there's not really a valid patent on those two tools, we all use them frequently to stuff food in our mouth. But imagine if somebody stuck a tax or license fee or has a patent on eating a chicken using a knife and fork.

With all that said, there may be capabilities in tickets CAD that are going to get stripped out of it, or never delivered, because of these patents.

Machine learning, statistical models, LLMs, they are a prior art and were designed for analyzing data. How does everyone feel about patents being issued because of the data that these tools are being used on?

I'm picking on just one use case here, this is not the only concern. 

Push to talk on a mobile device, caching a map, there are others I won't list out here, but just wanted to mention that there are threats to open source software all around. Maybe the vendors will be excited about the fear this creates and can use that to sell you a very expensive product.

To view this discussion visit https://groups.google.com/d/msgid/open-source-cad/CAGVvMho0Um7voKE%2B%3Ds98PkxySdivEAsP97N-Usd7phShJRO4KA%40mail.gmail.com.

[Gerald Hurt]

Is the beta program still open? I did see in a different thread that the public release would be very soon.

[Eric Osterberg]

Yes, Registration is still open. A GitHub account is required, and installation with Git is preferred as updates are still coming and Git makes this very easy.

2 people ~recently~ applied but did not provide their GitHub account information.

I've had a few schedule interruptions so will likely be this weekend before I have a chance to return to working on anything but important fixes. Cleaning up old artifacts, design documents and secrets remaining in the test harnesses needs to be done before the public release. 

To view this discussion visit https://groups.google.com/d/msgid/open-source-cad/dd418155-9d47-467a-95f0-c15a9baf7644n%40googlegroups.com.