Fork it.

I had a funny double-entendre ready to go for this article, but I was talked out of publishing it. You're missing out on my excellent, if dark, humor - and I'm sorry.

Fork it.
A screenshot of the Mission Control repository

I'm giving up on the FSL as a realistic option moving forward. Looks like we're back to real open-source after all.

What does this mean, exactly?

You're in for a long one if you brave reading the entire article.

Both Mission Control and Starbase are being released under the highly permissive MIT open-source license. In practice, anyone can obtain the software for any purpose, including to use, copy, modify, merge, publish, distribute, sub-license, and/or sell copies.

The only MIT License restriction is that the "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."

But...why change course now?

I got some legal and professional guidance which has convinced me that the FSL wouldn't cover our projects the way I thought it would.

Specifically:

  1. For a license to be enforceable, it must be enforced. I have no plans of adding telemetry and I don't want to have (or incentivize) customers snitching on anyone. Nor do I have the resources (or desire) to outsource license compliance.
  2. Building an FSL web application on top of an MIT Licensed framework (Laravel) is possible, but requires great care to do correctly. Essentially, the increase in complexity to manage this licensing scheme is probably not "worth the squeeze," especially at our size.
  3. It's unlikely the issue I'm trying to solve by using the FSL is actually going to happen (a big company taking benefits while withholding contributions) especially in our somewhat niche Amtelco ecosystem.
  4. In rare cases, it can reduce the legal risk of building against a 3rd-party ecosystem and protect against cease-and-desist take-down requests.

From a personal belief-system standpoint, there's also been some cognitive dissonance around whether I can support the concepts of open-source while also pushing a non-open source license (even if open in spirit.)

As a result, I chose to go with the option that is likely long-term better for my customers, but short-term not as good for my business: the highly-permissive open-source route.

Business schools should study me [for what not to do]

The Imposter Phenomenon

I like calling it a "phenomenon" instead of a "syndrome" – it sounds better?

If you don't know what it is, Wikipedia tells us that Imposter Syndrome "is a psychological experience in which a person suffers from feelings of intellectual and/or professional fraudulence."

The part "suffers from feelings" does a lot of heavy lifting. In many cases, it's only a perceived doubt.

For example, Wikipedia continues: "the subjective experience of perceived self-doubt in one's abilities and accomplishments compared with others, despite evidence to suggest the contrary."

And let me tell you: it's a real thing. Many of you have probably experienced Imposter Syndrome even if you didn't recognize it. For me, it goes hand-in-hand with the saying "Perfect is the enemy of good." I'm currently wading through a river of anxiety in the lead up to releasing these products:

  • What if a peer makes fun of my coding style? (this already happened)
  • What if a competitor takes my product and makes it better?
  • Will I be able to avoid special/self-interests in favor of project health?
  • What if it's not good enough for someone's use case?
  • What if I publicize some previously unknown security hole?
  • What if my tests are incorrect or my formulas are wrong?
  • What if I struggle to adapt to a multi-contributor environment?
  • What if I don't even have actually useful tests?
  • What if I accidentally committed an API key or credential in the past?
  • What if someone reviews old commit messages and questions my sanity?

While there are a variety of tangible actions I can take (use AI to write better tests, pay for a 3rd-party security audit, squash commit messages, etc.) there are a variety of concerns that I need to address both organizationally and personally before publishing these products live.

These articles take a while to write, so I've actually open-sourced Mission Control under the MIT license since I began writing! Check it out at github.com/calltheory/mission-control

Tricking capitalism into working for me

So now the question becomes: how will I make money? I know! The same way I was making money on these projects before: ????!

As you can see, I am ever the astute business-person.
green plant in clear glass cup
Photo by micheile henderson / Unsplash

Trying to bundle products into the Call Theory Technical Support plans never really worked. Nobody signed up for a plan specifically for Mission Control (although those that use it seem to like it.) I tried various ways of "including" the license for customers, but wasn't ever able to get any real traction.

As the product has matured (and with the addition of Starbase) I needed to find a way to actually make money without forcing sign ups to Call Theory. This means it's time to de-couple Mission Control from our subscription, further supporting the ability to open-source things. We talked about this a few weeks ago.

As for the business plan, I'm keeping things simple.

  • The software is as open-source as it gets. Anyone can download and use it for virtually any purpose.
  • We will offer paid installation, support, consulting, and hosting plans for both Mission Control and Starbase. (You can see the pricing live now)
The version that we use for hosting is the same version available for download.

Let me know if you have any feedback, but yes – I do plan on adding some sort of bundle for Mission Control and Starbase at some point. The installation, support, and hosting is similar in scope as they are both based on the same underlying framework.

Perhaps bundling these is how I can offer sales/deals from time-to-time (something I've historically avoided on the Call Theory plans.)

The New Call Theory Plans

Let's start with Call Theory. This is where we provide technical support and training for call centers and it represents our largest grossing product.

The primary change to these plans is that the licensing portion of Mission Control was removed. Since we went with MIT licensing, there is no licensing required from Call Theory to use the product anymore.

We did add included support for Mission Control and Starbase to our Power Up plan and included installation on our Level Up plan so existing customers don't have to pay additional support fees.
calltheory.com/pricing

The New Mission Control Plans

First and foremost: you don't have to pay anything to use Mission Control anymore. You can download the source code and use it for virtually any purpose. We would love if you contribute back improvements and bug fixes but you aren't required to.

However, if you don't have the technical acumen or just need to give yourself less responsibility, we can do all the heavy lifting for you. We offer one-time installation and ongoing application support for those of you who want to get thing setup in your environment.

We recommend you use this method over paid-hosting. Having some level of ownership over your infrastructure is one of the major benefits of using Mission Control.

The New Starbase Plans

In addition to Mission Control, we've got the same thing going for Starbase. Support, installation, consulting, and hosting are available, but you can do everything on your own if you prefer.


Mission Control is a go, Starbase Is Next

As you might have picked up on, the Mission Control dashboard has already been published (publicly) under the MIT license.

GitHub - CallTheory/mission-control: A web-based utility dashboard for Amtelco call center environments
A web-based utility dashboard for Amtelco call center environments - CallTheory/mission-control

It's a new repository, and I made substantial updates, so you won't be able to just "swap" to the new open-source repository without taking steps to install the necessary updated libraries and handle the missing git history.

I will be moving customers to the latest open-sourced version over the next couple of weeks.

The updates that were made specifically for open-sourcing the project include:

  • Making all existing tests pass, and expand test coverage
  • Remove most Call Theory branding and replacing it with Mission Control
  • Squashing my historically un-audited commit messages
  • Finding and fixing easy-to-find security issues
  • Updating framework libraries and dependencies
  • Removing test/unused features that never made it into production
Fun fact: Mission Control has actually always been licensed under the MIT license, we just didn't publish the repository publicly.

But seriously, what about Starbase?

  • License change from FSL to MIT is in done.
  • Tests are all passing, and I've added more.
  • I'm finishing up localization (language support) this week.
  • The database demo mode (where we have semi-real data to demo and test with) is done!

That last point has been the hold-up to date. While the feature is done and appears to be working, I'm still in the process of writing tests (which I'm already not great at) to ensure everything works properly and consistently.

So to sum everything up: expect the fully open-sourced release of Starbase shortly. I've been pretty tight-lipped about things (to the chagrin of my customers) but thought I'd share another generic screenshot in the meantime.

Starbase Database Connectivity

Call Center Village - Looking For Sponsors

The Call Center Village Logo and Icon

If you haven't heard, we're running a security village called Call Center Village and have been accepted into a few conferences (since NAEO) including Hackers Teaching Hackers and DEF CON 33.

We're also throwing a party at DEF CON 33, so if you're attending for any reason please let me know and I'd love to have you join us.

Speaking of which, we're looking for sponsors for both our village and our DEF CON 33 party! Here's what we need:

  • Money to provide drink tickets to party attendees
  • Sticker donations to give out to party attendees
  • A phone booth. Seriously. I'm going to make this happen.
  • Used/out-of-service equipment donations for new challenges.
  • Any cool phone ambience ideas you might have!
Call Center Village’s Party Line @ DEF CON 33 - Call Center Village
Join us at Call Center Village’s Party Line, an after-hours party open to all DEF CON attendees! Help us celebrate the human operators who make call centers and answering services more usable, accessible, and private.

Social Engineering testing for your call center?

I'm also highly interested in any call centers that would like to be tested extensively by real security professionals attempting to extract information from a fake account in your system.

This is part of the Call Center Village challenges and I'm extremely grateful for the customers who let me do this now!

Essentially, we setup a fake account (only known to you) and then setup moderated phone-calls for security professionals attending our village to talk directly with your agents and get information about your account and/or system that they shouldn't otherwise be privy to.

The commitment is low, with call volume corresponding to public village time -frames. Additionally, your DIDs are not shared (as we forward our own disposable numbers and don't publish yours.)

If you're interested in participating we'd love to hear from you. Hit reply and let us know! It's a great opportunity to test out new options for verifying authenticity of callers, something our industry is bound to be burdened with - thanks to our AI overlords.

Office Hours

We'll have next month's office hours and scripting sessions schedule sent out within the next few days, so make sure you're subscribed to the Office Hours & Scripting Sessions Updates newsletter in addition to this one (same spot, just two different newsletters.)

Or check back at blog.calltheory.com regularly

Talk soon!