What it means to develop in the open

6. August 2019
Time6 min read

Originally published on the Flipside XR blog.

Developing in the open means taking the open-source concept of release early, release often and applying it to a commercial product. It means updating users frequently and transparently. It means showing your unfinished work, listening to and learning from your users, and adapting to their feedback.

For us, it meant putting a Flipside Studio update out on average around twice per month since launching into Early Access in March, 2018. That’s a lot of updates.

Some updates are just a bunch of bug fixes. Others include new features or new sample content to show what’s possible with Flipside. And often, we’re balancing Flipside updates with other things that help keep our company afloat, such as helping our customers with various aspects of their shows.

Why we chose to develop in the open

In hindsight, I’m not sure we had a choice. Flipside is a really big idea (and nowhere near being fully realized yet), and to get from here to there at some point along the way you have to have something to show. A product for people to use. Preferably one they find valuable today, even if you know it’s still just one part of some larger vision.

Matrix meme - What if I told you your feedback could determine our future?

So when we felt we had an MVP of the first usable part of that vision, we put Flipside Studio out into the world. Followed a few months later by the second part of that vision, our Flipside Creator Tools plugin for Unity.

While we’re often thinking years ahead when we think of what these products are going to grow into, it takes discipline to ground yourself in what it does for users today. Having a community of users tell you what they think of your stuff is a great way to get grounded to the reality of providing tangible value today.

We didn’t know how hard it was going to be

I’ve run various open-source projects over the years, and I still maintain a few smaller ones on the side. So I knew users can be brutally honest.

But it’s harder to take that brutal honesty when you also know it’s going to take a long time to be able to satisfy their wants or needs, and that’s closer to the reality of Flipside than my past open-source experience.

Open-source users can also sometimes fix things themselves, so there's often less need to do everything yourself. And most open-source software is a volunteer effort.

But the big reason things take longer with Flipside is in large part due to the fact that it is an order of magnitude harder to make a multiplayer virtual reality TV studio than it is to make your average web app (Flipside has an extensive web back-end, too).

Taking feedback

Feedback is an interesting beast. It's often terse, even when it's not harsh. Many people prescribe a solution without fully describing the problem they're having. Many people ghost after the first terse suggestion, leaving no opportunity for clarification. And feedback is inherently given without knowledge of your other goals or long-term vision for your app.

Game of Thrones meme - Brace yourselves, constructive criticism is coming

But without taking feedback seriously, your long-term vision is almost certainly going to be out of touch with reality. So it's very important to listen carefully. It's also very important to drill down to root causes and assimilate the feedback with the larger context you have for your app.

Doing so will mean the difference between tacked-on features and features that fit more coherently over time. That doesn't mean they'll be perfect out of the gate, but they'll make sense in the context of both your users' goals and your own.

Fostering community

Fostering a community around your software is time consuming work. It can also conflict with other areas of your life, especially for an app like Flipside that many people are only going to use outside of 9-5 hours.

We've also made a lot of mistakes in that process. We scattered our community across various social media sites. We provided a roadmap that users couldn't contribute to. And when the team gets too busy and starts to feel overwhelmed, we tend to drop off in community participation. And the truth is, you have to be present in your community or it says you don't care.

The key is to learn from your mistakes and find better tools or processes. Like encouraging a centralized place for the community to chat on Discord. Or using Trello for our roadmap so users can make suggestions, comment, and vote.

Not everyone on your team is going to want to participate in the community, for a variety of reasons, and forcing them to do so isn't going to work. It can also seriously impact their productivity in other areas. But it's super helpful for users to know they can @mention or DM one of us for help and we'll at least get you in touch with the right team member.

Cat meme - Don't worry, I'm from tech support

For our team, we're too small to have any one person dedicated to community management (along with social media, marketing, and the umpteen other hats we regularly share), but we try to make sure one or two of us are regulars on Discord, and we make a point not just to get back to people, but also to champion our users and their creations whenever we can through our social media.

How developing in the open made our app better

Users see your app differently than you do. They see it strictly in terms of its usefulness to them. At various times, you might see your app as everything from your baby, your livelihood, your dreams, or that thing that won't let you sleep. But none of that makes your app better. It only clouds your ability to see your app for what it truly is.

Users, on the other hand, know what they want to accomplish through your app. And we're just fortunate enough that some will tell you when it isn't working for them. Good app design isn't about getting your users to do something you've designed for them to do, it's about helping them do something they want to do.

It's a small distinction, but there's an important lesson in it: The best user experience is one where the user is able to forget about the tool and just do the thing.

As a developer, it's tempting to think that that makes your job less rewarding, that your work being less visible diminishes it, but that's not true. The output of your users is what your app makes possible, and that's a stronger source of inspiration anyway.

Users being honest keeps you seeing your app clearly. It keeps you honest with yourself about your app. That's why even though users being brutally honest is one of the toughest parts about that relationship, it’s also one of the best parts. Your app and your business need brutal honesty, and you’re often less likely to get it from someone the closer they are to you.

So while it’s been hard at times, it’s also given us a steady push that has allowed us to watch our app take shape in ways it never would have without them. That’s something special.

Go you, you're amazing!

In retrospect, I don't think we could successfully develop Flipside in any other way, and we're very grateful for our community, their encouragement, their honesty, and their patience. We're in it for the long haul, and we're going to need the ongoing support of a community not to burn out along the way.

Here's a little video reel we made to celebrate what our amazing community have been creating in Flipside: