Open is Not an Afterthought
 |
| I will make this one day |
If you're a developer, product manager, entrepreneur, etc. wondering if you should make your "thing" more open, yes you should figure out how to open it -- even just a little bit -- right away. You probably should have been thinking about it a year ago. Open (like accessibility, incidentally) isn't really something you tack on after-the-fact, it's a whole lot easier in young projects. And for me it hasn't typically been something that happened naturally. You usually have to fight for it.
Open is great for a lot of reasons. It gives your team something not-hidden that they can feel pride in, it forces you to think about the *real* reasons why you're doing something, and of course it lets others build on top of your stuff. Open is about the unexpected leverage that someone else finds without your help. In my experience those discoveries typically happen later than you expect them to, but obviously not at all unless you first open things up. And in the end they're big success stories for you and your users.
Example time.
 |
| Our logo is open in the middle. Coincidence? Mostly. |
The only reason Canvas has an open API is because we decided we should have one. When we started building an iPhone app back in 2011 we decided the app would only use public API endpoints -- if they didn't exist, we'd write them. Later we extended that rule to new features in Canvas proper as well. It didn't provide short-term benefits other than maybe code hygiene and it took more effort to build third-party-consumable endpoints. But now we have somewhere around a million third-party API calls per day from lockdown browsers, portfolio and analytics tools, alternative gradebooks, badging apps, and other neat projects. People enjoy building on top of Canvas because they can just create something cool, no babysitting required.
When we first started building Canvas we really wanted it to be open source. It was important to me and Devlin as developers for many (some admittedly naive) reasons. Every investor we talked to would get hung up on that bullet point, though. How would we make money off people running the codebase locally? Were we going to offer support contracts? Were we a SaaS company or a support company? We eventually conceded, assuming they knew something we didn't, only to circle back and find a business reason for "going" open source in 2011 (side note: our initial commit message was an easter egg that no one ever caught. Too subtle?).
We also have always worked to have an open relationship with our customers and users. Back when we were still piloting with a couple dozen teachers, we decided that we were going to include our customers deeply in product strategy. It made sense to us because it's what we'd already been doing with our Product Validation Tour of a Metro and a slide deck. With every new customer we sat down and talked through problems, sometimes finding creative (read: wonky) workarounds to just get things done. We were straight with them about our shortcomings and our future plans, and expected them to be honest with us about their needs vs. wants. Now it's a foregone conclusion that our client services teams will work *with* customers to find solutions to problems, and I love it.
The "open" bullet point I'm most proud of though is the open architecture we're still building. When I first heard about LTI (an interoperability standard in edtech) I got really really excited about the promise it offered and threw together a Canvas implementation as quick as I could. Nobody really cared back then, and it was obvious pretty quickly that LTI didn't quite hit the dream Devlin and I were talking about back in 2008 (we bandied the idea around with Jon Mott in 2009 too), where LMS components like discussions or gradebook could be replaced with alternatives. So we started extending LTI to get it to where, combined with our open API, you really could swap out whole features in Canvas. Now when edtech startups decide to integrate with an LMS they come to Instructure first because it's the easiest integration (plus our documentation is slick).
 |
| Why did he write on his head? |
This is starting to sound like a brag-fest, sorry. My point is, every single time Instructure took a step toward openness, it was premeditated. And there were naysayers. And the business value was unclear. And we did it anyway. And in the end it definitely paid off. We've often had to win over new people at Instructure to the value of open, and we still do sometimes. But once they experience it for themselves then they're usually on board after that.
I'm a believer in open because I've seen the difference it's made at Instructure. Frankly, if your company can't get over what might happen should you open up your code/content/API/platform/communication then you either have the wrong kind of competitive advantage or you're not valuing your users as much as you should. People who think lock-in is the same as customer stickiness aren't in it to improve the user experience. Opening up doesn't provide immediate returns. But gradually it wins over a few early adopters, then a few more, and then things really get interesting when you start to find those exciting ideas that someone else came up with. Ideas that make a difference that wouldn't have been possible without being open.
Comments