Project Motivations

At the most pragmatic level, I created and continue to maintain Media Masher in hopes of attracting freelance web development and consulting work on projects that are making the changes I want to see in the world.

In my estimation, most of these projects are in the media space, since changing minds is an effective way to change the world. Open sourcing my solutions for this specific use case keeps me from reinventing the wheel for each project, and increases the market value of my time.

Democratizing Media

The original motivation for releasing the source code was… anger! At the time there were just a couple browser-based video editors, and neither were open source or free to use. One was sold to Yahoo and they eventually allowed you to deploy it on your own site, but only if you could agree to push half a million dollars worth of their ads a year.

It galled me since their system, like mine, was a fairly simple layer atop Flash. And I felt like podcasting and vlogging (as we called it then) should be as free and ubiquitous as blogging had become.

So I first publicly documented all the work I had put into mine. Then I threw a price tag on the whole business that was considerably lower than what Yahoo had paid, but more than I’d ever seen in my life. It was kind of a joke because I didn’t think anyone would see my post or take it seriously.

But it actually drew some media attention, and then a swarm of venture capitalists with unscrupulous offers in hand. Some were tempting but ultimately the whole culture grossed me out, and I decided to give the code away. It didn’t even take a year before the landscape shifted. Two other free editors entered the market, both those companies were rendered worthless, and my time was all booked up.

Empowering Amateurs

This motivation originally came from the team who hired me to build the very first, closed source version of the system. Their requirement was to allow merchants in rural India to use their phones on dodgy cell networks to upload a photo they could combine with text to produce some sort of animation. This had to eventually be transformed to a high quality video ad for broadcast over their satellite television network. Nothing at the time was allowing such an amateur userbase to create production-grade video in such a constrained environment.

These requirements stayed in place as we added support for video and audio uploads, font choices, and effects. The ethos behind them served the project well after it was open sourced and starting to be used in other contexts. I got particular joy helping educational outfits deploy the system in classrooms. And a real thrill when a manufacturer deployed it to their drone fleet.

Today, I want to enable media creators to enlist help from their audiences in getting the message out. Specifically I want to work on systems that allow viewers to edit down media into highly targetted shorts they can then share on social media.

At least among the creators I follow, it seems they all struggle to produce as many shorts as they’d like. I aim to provide a safe, moderated solution that capitalizes on their audience, while allowing their production team to focus on polishing the actual content. The audience actually knows best what parts they want to highlight, and how they want them packaged.

In addition to empowering audiences to take part in the production process, I hope to keep the system simple enough that any amateur web developer can deploy it. This was the motivation behind making the Media Masher API publicly available and offering cloud storage and processing as a service.

The first thing most clients want us to deploy for them is a testbed where they can play with the system and figure out how to integrate it into their existing site and admin. Now they can do this on masher.media without even becoming a client. The services there are robust enough to use in production if desired, but the expectation is that some or all of them will be replaced by the client’s infrastructure at some point during deployment.

Transparent Pricing

My business model is simple: revenue mainly comes from providing support, billed by the minute, rather than from subscription fees or overpriced cloud infrastructure with confusing tiers. It’s a pay as you go model. The cloud resources you consume are priced quite close to the actual AWS costs, and the primary goal of the support is to help you avoid them whenever possible.

For a detailed breakdown of how costs are calculated and the rationale behind them, see the Pricing page.

Embracing Standards

I’ve been developing interactive networked applications since even before the web, and have witnessed a dazzling array of standards come and go. Many of them have been nefarious attempts to capture evolving markets, while others have become the bedrock of what we all build. It is often difficult to sort them in realtime, and some pernicious attempts ultimately succeed in becoming foundational.

With this in mind, it’s easy to embrace most web standards. Certainly HTML and CSS standards are very well vetted and should be relied on heavily. JavaScript standards are more of a moving target… Obviously, at the syntax level modern language patterns should be followed, and media handling is more or less consistent at this point.

But different browser vendors have different priorities and security concerns, which results in conflicting standards, especially concerning files - same story with the various server runtimes. I tend to just avoid features that aren’t well supported or can’t be easily patched, though sometimes we must.

I will always prefer to support standards that are derived from a democratic and open process over those proposed or controlled by a private company. You can hire us to build you something in React, for instance, but Media Masher only ships with a Web Component implementation.

In addition to protecting from the abuses of private capital, this is simply the more efficient approach since the browser already has the component handling code and executes it exponentially faster. The vast majority of folks I see using React aren’t using any of the features that distinguish it from Web Components.

Avoiding Lock-in

I hate and avoid vendor lock-in and you should too! Even more insidious is mental lock-in, keeping us all from envisioning more independent architectures and approaches to solving the problems we choose to tackle. Late stage capitalism has evolved quite elaborate mechanisms to lock us all in, and is working hard to literally lock us developers out of the process entirely with their so-called AIs.

Step one towards walking away from this whole mentality is to eradicate it from our own applications. Out of the box, Media Masher uses a variety of local-first technologies to put end users in control of the media they import and data they create. This makes it easy to support standards like GDPR, and provide other privacy protections.

On the server side, it’s relatively simple to reconfigure which regions a user’s files and data are stored on. This makes it easier to adhere to various legal requirements you may have in different jurisdictions.

In addition to making it easy to avoid locking in your users, I strive to make it easy to walk away from Media Masher too at any point. You can take baby steps in that direction by developing plugins that can control any part of the process on the client or server. Or feel free to completely rewrite any part of the system - the license more or less allows you to do whatever you’d like with the code.

If you decide to build a completely different system, you still may not have to abandon the data model. But even if you do, you’ll find it easy to work with as you export and transform the data into something more suitable for your purpose.

Staying Independent

I am the sole owner of the company, which is a Benefit Corporation registered in Vermont, USA. Beyond the reporting requirements this designation entails, providing a public good is the overriding consideration in all decisions. To this end, the long-term continuation of the company as it currently exists is the highest priority.

This independence is made possible by a simple, old-school business model. Instead of profiting from reselling cloud services or tricky contracts, revenue comes from providing direct, one-on-one support, consulting, and programming services. This aligns our incentives perfectly. I’m here to help you get the system working on your site, customize it for your audience, or solve whatever technical problem is stumping your team.

The growth mindset can be very alluring… who doesn’t want their audience and enterprise to grow? It’s a slippery slope though when you start trying to build value in a company - the higher that value gets, the more you’ll be tempted to sell out in one way or another.

The growth I find exciting is in the number of people who feel they are creators of some sort. The only growth I envision in the company would be to the number of people like me providing support.