These are the news items I've curated in my monitoring of the API space that have some relevance to the API definition conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is testing their APIs, going beyond just monitoring and understand the details of each request and response.17 Apr 2017
Everyone once in a while I get a comment from someone regarding competition in the API storytelling space, alluding to someone getting the page views, or audience when it comes to APIs. I rarely worry about these things, and in reality, I want to see way more competition and outlets when it comes to short and long form API storytelling--the API space needs as many voices as it possibly can.
I'd like to see domain specific evangelists emerge, beyond individual API advocates. Someone covering industrial, machine learning, healthcare, and other significant verticals. We need to begin to cultivate domain expertise, and preferably vendor-agnostic, and tooling-comprehensive knowledge and accompanying storytelling. Some of these verticals are in desperate need of leadership, and I just don't have the time to focus in on any single area for too long.
We need more practical, and hands-on API storytelling like we are seeing from the Nordic APIs. They are rocking the storytelling lately, exceeding the quality I can achieve on API Evangelist. They are hitting all the important areas of the API life cycle, and their storytelling is genuine, useful, and not pushing any single product or service. The Nordic APIs is invested in educating the community, something that makes their work stand out--emulate what they are up to if you need a model to follow, don't follow mine. #seriously
If you are an API provider or possibly aggregator and marketplace, consider following the lead of BBVAOpen4U API Market, they produce some interesting content, as well as also have a good way of sharing and syndicating quality content from across the API space. I've seen a lot of companies come and go when it comes to aggregation and syndication of API stories. I like BBVA's open approach, because they have skin in the game, and seem to genuinely want to highlight other interesting things going on in the space--something more API providers should be doing.
If you want to get started in the space, all you need is a blog, a Github, and Twitter account. Come up with a name, and begin learning and writing. Don't worry about page views, or having a voice when you first start, just write. Then as you feel comfortable, and find your voice, begin sharing your work more, as well as highlight the work of other storytellers in the space you are learning from. If you keep at it for a while, you never know, you might actually build a following, and be able to influence the world of APIs through the stories you tell--give it a shot.
I was playing around with, and better understanding the new collaborative developer community that is Glitch, and I saw they had published a blog post about how they won't screw up Glitch. The topic was in alignment with another post I was working on regarding what I'd like to see fro API startups, but I think Anil articulates it better than even I could, and I think folks are going to respect it a lot more when it comes from a seasoned veteran like him, over an opinionated evangelist like me.
- We’re not gonna take features away from you and then start charging for them. This is one of those tricky things that a lot of companies do when they start building a business model for their productâ—âthey ask, “what would people pay for?” And then they realize… oh crap, the stuff people want to pay for is already offered for free. We’ve thought about this pretty carefully so we’ll be able to support our current features going forward. (It doesn’t cost much for us to run your Glitch app, and that cost is going down each month. No biggie.)
- When we do start charging for stuff, we’ll check with you first. We imagine we’ll add some paid features on top of what Glitch has now (maybe domain names? Everybody loves mapping domain names!) and when we do, we’ll let you know they’re coming, plus get your feedback on what you think is fair and reasonable pricing. Because we want you to be happy to pay for these valuable features!
- We won’t let a bunch of jerks take over the community. Ugh, this one is so annoying. Usually, when a company is trying to grow a community, they’ll let just about anybody in because they’re desperate to show growth, and that inevitably means opening the door to some small number of jerks, who then ruin the whole site for everybody. Instead of doing that foolish thing, we’re going to grow Glitch steadily and deliberately, with tons of room for new folks, but a lot of thought put into preventing abuse and harassment. I can’t guarantee we’ll get it perfect, but honestly the thought of working every day to build something that’s mostly used by jerks would be awful, so we’re not gonna do it. And honestly, Glitch is growing pretty quickly because it’s friendly, so hooray for nice people.
- We want your fun and weird and “not serious” stuff on Glitch, too. While we’re ecstatic to feature Serious Tools from incredible companies like Slack on Glitch, we think your artsy or silly or deeply personal projects are vital to the community, too. The same people who spend their day building a complex API integration on top of Glitch’s tools will come home and collaborate on a generative poetry project at night, and that’s exactly what we’re designing for. So don’t feel embarrassed to show all your many facets here; that’s what our own team does, too.
There are other things I'd like to see other startups focus on like privacy and security, but Anil really get's at athe heart of much of the illness we see regarding API startups. For me, it really comes down to communication and honesty about the business model, which Anil talks about in a very approachable way. I don't expect companies who are doing startups to do everything that us developers want, but I do want you to be open, honest, and communicative with us about what is going on--that is all.
I fully grasp that startups are in the business of making money, and often have different motivations than many (some) of us developers who are consuming their API focused resources. I do not expect these things to always be in perfect balance, but I do expect startups to be honest with developers from day one, and not bullshit us about their business model, changes and the long term road map. I appreciate that Anil and the Glitch team has started things off on this foot, hopefully providing the rest of us with a model to follow when it comes to not screwing over your developer community, and building more trust when it comes to depending on APIs across the sector.
I am looking forwarding to learning more about Glitch, and the potential for the community.
I saw an interesting chasm emerge while at a Google Community Summit this last week, while I heard their support team talk, as well as their developer relations team discuss what they were up to. During the discussion, one of the companies presents discussed how their overall experience with the developer relations team has been amazing, their experience with support has widely been a pretty bad experience--revealing a potential gap between the two teams.
This is a pretty common gap I've seen with many other API platforms. The developer relations team is all about getting the word out, and encouraging platform usage and support teams are there to be the front line for support and being the buffer between integration, and platform engineering teams. I've been the person in the role as the evangelist when there is a bug in an API, and I'm at the mercy of an already overloaded engineering team, and QA staff, before anything gets resolved--this is a difficult position to be in.
How wide this chasm becomes ultimately depends on how much of a priority the API is for an engineering team, and how overloaded they are. I've worked on projects where this chasm is pretty wide, taking days, even weeks to get bugs fixed. I'm guessing this is something a more DevOps focused approach to the API life cycle might help with, where an API developer relations and support team have more access to making changes and fixing bugs--something that has to be pretty difficult to deal with at Google scale.
Anyways, I thought the potential chasm between developer relations and support was worthy enough to discuss and include in my research. It is something we all should be considering no matter how big or small our operations are. There is no quicker way to kill the morale of your API developer relations and support teams by allowing a canyon like this to persist. What challenges have you experienced when it comes to getting support from your API provider? Or inversely, what challenges have you faced supporting your APIs or executing on your developer outreach strategy? I'm curious if other folks are feeling this same pain.
It is tough to keep a sustained fire burning in the world of technology, at the individual, organizational, and community level. I have been doing API Evangelist full time for six years, and it is no secret that I have had several moments where I've experienced a crisis of faith, and I do not doubt that there will be many more of these in my future--there is no perfect solution. It takes hard work, creativity, and a myriad of other considerations to keep going, stay energized, and keep other folks doing the same.
I have spent a great deal of time this fall thinking about all of the factors that influence me, and contribute to the fire burning, or acting as a flame retardant to me and the API space. When exploring these contributing factors, it is only logical we start with the external forces right? Because this all sucks because of everything external, aka all of you! Couldn't possibly be me?
So what are some of the external forces out there that contribute to the fire burning brightly, or possibly being dampened across API space are?
- People Aren't Always Nice - For some reason, the Internet has brought the worst out in many of us. I personally feel this is the nature of technology -- it isn't human, and the more time you spend with it, the less human we are, and less empathy we will have for other people.
- Everyone Takes A Little - Until you've spent a great deal of time in the spotlight writing, speaking, or otherwise you don't fully grasp this one. Every person you talk to, every hand you shake, takes a little bit from you -- making it super critical for people to give back -- it all takes a toll, whether we acknowledge it or not.
- Few Ever Give Back - The general tone set by startup culture and VC investment is to take, take, take, and rarely give back. The number of people who want to pick your brain, take your open work, and not ever give anything in return is far greater than the people openly giving back, or acknowledging they should pay you for your time.
- Use & Subscribe To Open Channels - Follow me on Twitter, and Medium. Subscribe to the Atom Feed and email newsletter. Support those people in the space who provide open channels of information by tuning in and engaging.
- Fork, Contribute & Build Upon - When you fork someone's work plan on how you will contribute back, build upon, and cite their work. Don't just use open source, contribute back to it, and augment it with the value you bring to the table.
- Events Are Exhausting - Producing, organizing, and pulling of valuable events that focus on ideas over products are fucking hard, and you should support the open tech events you think contribute most to the tech space. Invest time, money, and your energy wherever you can afford it. I know your company demands you get the most out of your sponsorships, but step back and consider how you can give the most as part of your sponsorship as well.
- Where We Invest - 95% of the investment in the APi space is into proprietary products, services, and technology. The other 10% is an equal investment in ideas, open concepts, specifications, definitions, and software. If companies do invest in "open" it is in name only, and not a true invest. Everyone suffers from this behavior, making the space pretty fucking business as usual--which is a fire that nobody wants to tend to for very long.
- Intellectual Property - Unhealthy views on IP lock up ideas. I'm not saying copyright, patents, and licensing shouldn't exist. I am saying that aggressive, greedy views will continue to act as a wet blanket when it comes APIs making a meaningful impact, and making the game pretty untenable for individuals.
Next, up, what are some of the internal forces (aka my responsibility) that can contribute to the fire burning more brightly in the API space?
- Going To Burning Man - Yes burning man will reinvigorate you each year, but we have to find a way to establish a regular alter that we can burn on a regular basis, finding renewal on a regular basis without so much fucking dust involved.
- Eat Well - If we've learned anything over the last six years it is that man cannot live on pizza alone. Words of caution for you youngsters--eventually you will start falling apart, and this shit will break if you do not eat well.
- Alcohol - Drinking is fun and an important social lubricant, but it can also lead to some very bad behavior in real-time, as well as contributing to a multitude of other issues in life ranging from health to relationships.
- Exercise - We just can't sit on our ass all the time, as much as we'd like to think we can. Again, this isn't a problem for the youngsters, but as we get on in life, it will catch up with you, and we are better off finding a way to work it in regularly.
- Family Time - Spending time with family is important. Too much travel, screen time and work all hurt this. Regularly check in on what is important when it comes to family. Even if it is just working on API integrations with your kids (did I tell you I'm doing a project with my daughter) -- woohoo!
- Creativity - Take time to invest in and move forward creative projects. All work and no play makes us all very fucking boring, and are not conducive to any flame burning. The less I invest in my creative side, the less productive I am in my regular work. As an individual and a business make sure there is the investment in creative projects and space.
- Money - Money is not everything, but making some is required. I've had several waves of $$ making good in my career, and it rarely ever brought me more happiness, and always brought me more concern. There is a lot of focus on VC investment, and showcasing the successful founders in the space. To keep a sustained fire burning we have to realize there is a lot more to all of this than just making money.
These are just some of the key external and internal forces contributing to the fire burning within me individually when it comes to APIs, and I also feel contribute the fire burning also across the community (which I am part of). Startup and VC investment success do not equal community and individual success. Rarely does a startup winning contribute to any single individual success, or the wider community being more vibrant, creative, and rich? You have a rare rock star founder, and always the wealth of corporate and brand success, but these do not make a fire burn brighter in the community. It might attract a few moths to the flame along the way but doesn't truly enrich everyone, and provide fuel for a sustained burn--it is about burning bright, fast, and hard, which aren't good for most of us humans.
I keep going as the API Evangelist because I'm interested in what I'm doing. I'm fulfilled by learning, writing, sharing, and building. I will keep going for another 10, 20, hopefully until the end of my life, because a real fire is truly burning--not because I met my sales goals, sold my startup, or reached API economy nirvana (that is API singularity). Most of the time I'm learning, I am being creative, and I've made more money than was required to pay my rent, my bills, and could eat well. More meetings. More projects. More handshakes. More money does not always nurture me, and keep the fire alive personally, or within the wider API community.
I am working on a project with a 16-year-old young lady to extract and tell a story using the YouTube API. I'm pretty excited about the project because the young lady happens to be my daughter Kaia Lane. If you've ever seen my API Blah Blah Blah t-shirt, you've seen her work. Historically she could care less about APIs, until recently when pulling data about one of her favorite YouTube stars came up--suddenly she is interested in learning more about APIs.
During regular chatting with my daughter, I shared a story on the entire history of Kickstarter projects broken down by a city. She is a little geeky and likes Kickstarter, so I figured I'd share the approach to telling stories with data, and said that if she ever wanted help telling a story like this using YouTube, Instagram, or another platform, that she should let me know. She came back to me a couple days later asking to learn more about how she could tell a story like this using data pulled from one of the YouTube stars she follows.
Ok. I have to stop there for a moment. My 16-year-old daughter just asked me to learn more about APIs. :-) As an old goofy dad who happens to be the API Evangelist, I am beside myself.
I'm not 100% sure where this project will go. Right now I'm just seeing what data I can pull on Dan & Phil's video game YouTube channel, and from there we'll talk more about what type of story we want to tell about their followers and get to work pulling and organizing the data we need. I couldn't think of a tougher audience to be trying to get her interested in APIs. She isn't going to care about APIs, wants to learn about APIs, let alone become proficient with APIs unless they are relevant and interesting to her world.
I do not think this lesson is exclusive to teaching 16-year-olds about API. I think this applies to ANYONE potentially learning about APIs. I am a big fan of EVERONE learning about APIs because they are the plumbing that moves our bits and bytes around in our personal and professional worlds. The more we are aware and the more we know we can put APIs to work, the more successful we are going to be in our lives. I want EVERYONE to open up and learn about APIs for this reason, but I REALLY REALLY want my daughter to find success in this way.
Just something to consider, as we are trying to help key internal, essential partner and other public stakeholders understand the API potential. How can we present APIs in a way that is relevant and interesting? Otherwise, most people probably aren't going to care, and it will all just be API Blah Blah Blah!
Another story I harvested fro a story by Gordon Wintrob (@gwintrob) about how Twilio's distributed team solves developer evangelism, was about how they invest in having a distributed team, providing an on the ground presence in the top cities they are looking to reach. I know this isn't something all API providers can afford, but I still think it was still an important approach worth noting.
Like with many other aspects of Twilio's approach, they are pretty genuine about why they invest in a distributed API evangelism team:
We also focus on interacting with the developer community where we actually live. We don’t think it’s valuable to parachute into a tech community, do an event, and then leave. We need to participate in that community and make a real impact.
I wish there was a way that smaller API providers could deliver like this. I wish we all had the resources of Twilio, but in reality, most API providers won't even be able to "parachute into a tech community", let alone have a dedicated presence there. I've seen several attempts like this fail before, so I am hesitant to say it, but I can't help but think there is an opportunity for evangelists in certain cities.
There isn't any startup potential here (let me make that clear), but I think there is an opportunity for developer advocates, evangelists, and would-be evangelists to band together, network, and offer up services to API providers. All you'd have to do is take the page from the Twilio playbook and execute in a decentralized way--where multiple evangelists could work together as a co-op. The trick is to bring together evangelists who actually give a shit about the space--something that would be very difficult to accomplish.
Anyways, just some more thoughts from my API notebook, inspired by Gordon's post. If nothing else, Twilio's approach should help guide other larger API providers, showing how important it is to invest in developers, in-person at the local level. The value brought to the table via Twilio's APIs has been key to their success, but I can't help but think a significant portion of their success has been the result of their investment at the local level.
I usually don't have to look very far to find good examples of API evangelism in the field, because the best technology providers are usually pretty consistent and vocal about their practices--allowing me to just pluck from my feeds, and rework as a story for my API provider readership. One of the consistent sources for me out there is from the Docker community, and from what they like to call Docker Captains.
One of the things I see regularly from this Docker community leadership is the sharing of their platform tips and tricks and in-person and online meetups. This is definitely something I recommend other API providers do when possible, but I would also recommend working to integrate the concept into your regular evangelism activities like blogging, weekly newsletter, and Tweeting.
Maybe it is something you could also open up to the rest of the community. Allowing your trusted partners, and your favorite developers to share what their tips & tricks are around API integration and usage are. The idea of tips and tricks is a pretty basic thing, but if you are working to stay creative in producing content, while also keeping things in the realm of actually helping your API developers be successful--it is one that can go a long way each week at meetups, on your blog, newsletter, Twitter, and across all the other channels you are already using to reach developers.
I see an increasing number of job postings on LinkedIn and other job websites from companies who are actively seeking an API rockstar, ninja, lead, owner, or product manager, and because of my connections in the space I know that some of the intent behind them are less than sincere. Don't get me wrong, I think ALL companies should be embarking on their API journey, and if that means bringing in outside talent--get it done!
My motivation in writing this post is to help companies be more realistic during their talent search, and hiring process, as well as internally with their teams. As an IT and lead developer veteran, I have been brought in to take the reins on a number of teams and I have seen a wide range of toxic situations. I understand the internal struggles exist in all companies, but the companies that were the worst for me, were the ones where I was blindsided by the depth of the entrenchment and struggle with leadership and internal teams, either because they were in denial or were straight up bullshitting me--in hopes I might be able to wave my magic wand and just fix everything.
I've confidentially heard many stories from API product leads, and evangelists after exiting a company, or sometimes while they are still in their positions, about how entrenched internal leadership is when it comes to "innovation" and "change"--all while putting on a good show that APIs are truly the priority. I understand that companies want to look innovative, hip, agile, flexible, and all the things often associated with APIs, but bringing in API talent, only to let them hit a brick wall because they were unprepared just isn't good business.
If you are going to say that you are doing APIs, and issuing press releases, and promising your customers, partners, and internal stakeholders that you are going to do APIs, make sure you properly prepare any talent you are looking to lead the charge. I'm not saying the API journey will be easy, and you shouldn't be embarking on this journey. I am just recommending that do not go around hiring API talent, only to blindside them upon entry with entrenched, unwilling to evolve internal actors...or if this is the case just make sure you set the stage properly during the hiring process.
Technology evangelists are nothing new, but are something I think is continuing to expand as the Internet continues to crack open more of the core areas of the tech sector. I specifically chose the term API Evangelist to define what I did evangelizing for all APIs, but all I was really doing is following the lead of evangelism pioneers like Amazon, Google, and even Microsoft.
There has long been discussion around evangelism vs advocates, and I've seen companies also choose to adopt an ambassador format. I have also been interested to see the evolution of Docker's Captain's program--who are "Docker experts and leaders in their communities who demonstrate a commitment to sharing their Docker knowledge with others".
I also stumbled across a post out of the MongoDB as a service provider Compose showcasing what they call the database advocate, whose "job is not to guard the database from the world but to advocate the best ways to use it and offering the tools to optimize that usage". In their view, the outdated DBA is going away, with the database advocate emerging as a much more friendly, outward facing, pragmatic gatekeeper for databases within the enterprise.
It makes me happy to see the open ethos brought to the table by web APIs spreading to all the layers of the tech stack, making the world of virtualization and containers more accessible. As an old database guy, it makes me really, really happy to see it also spread to the world of databases--I am hoping that it is something that continues to spread to all layers.
One reason for having a well thought out, comprehensive API strategy, is that you are thinking about all the moving parts, and at ever turn you can weave things together, and potentially amplify the forward motion of your API operations. With every new release you should be considering all other areas of your API strategy, how you can include your API consumers, your partners, and where all of the opportunities lie when it comes to evangelism, and storytelling.
This approach was present in the latest release from Postman, with the release of their Run in Postman, embeddable button. As part of the release of the new embeddable button for their API client tooling, Postman also made a call for partners. It was a savvy marketing technique to reach out to partners like this, something that will not just generate implementations in the wild, but will also establish new partnerships, strengthen existing ones, while also generating new blog posts, and press releases around API platform operations.
When it comes to the API Evangelist operations, the approach by Postman is gold--when I consider across many areas of my own strategy. Postman is showcased as part of my API client research, their product release exists within my embeddable API research, and also lives within my API evangelism and API partners research. The moral of this story is Postman thought across their strategy when crafting the release strategy for their new feature, and I also put in similiar thoughts across my own strategy while reading their blog post, giving us both an opportunity for establishing biggest bang possible, around a single API platform release.
API Evangelism Sometimes Seems Similar To The Environmental Discussion - What We Would Like, Does Not Reflect What Actually Happens On The Ground23 Feb 2015
I was just listening to segment on NPR, All Things Considered, about educating students around the environment. Throughout the program I couldn’t help be reminded of a similar imbalance in the world of APIs. Throughout my API experience I’m constantly faced with a separation between what I hear is possible, what I would like to see, and what actually occurs on the ground in startups, small businesses, and within enterprise organizations, and government agencies.
You might have to listen to the segment to fully grasp what I mean, but essentially it comes down to this: we’d like a perfect world where we do not negatively impact the environment, and everyone understands the urgency, but in reality there are a lot of real world constraints that prevent us from truly realizing this vision. In the world of APIs, these same constraints exist. We’d like to achieve API harmony in everything we do, but in reality there are a lot of real world constraints we have to navigate, from knowledge and education, to the time and resources needed to implement.
This chasm reflects the challenge in my API Evangelist mission. How do steer clear of selling people a single product, platform, or holistic vision of an API strategy, and break things into small, bite-size chunks of information that anyone can use (or not use) as they see fit, in the environments they operate within. I don’t believe there is a silver bullet, or single religion to follow here, it is all about staying in tune with what is working, and what is not—then making your own decisions about what is appropriate on the ground.
API Evangelist was born out of my success and failures working at SAP—which was all about striking a balance between what I knew was possible, what I wanted, and what was really possible in the environment I operated in. Alright, enough pontificating, and back to understanding all of this. I guess my point is, that this isn’t just about understanding where are going, where we’ve been or where we are currently—it is also about actually making meaningful connections that guide us, incrementally, in the right direction.
In my work everyday as the API Evangelist, I get to have some very interesting conversations, with a wide variety of folks, about how they are using APIs, as well as brainstorming other ways they can approach their API strategy allowing them to be more effective. One of the things that keep me going in this space is this diversity. One day I’m looking at Developer.Trade.Gov for the Department of Commerce, the next talking to WordPress about APIs for 60 million websites, and then I’m talking with the The Church of Jesus Christ of Latter-day Saints about the Family Search API, which is actively gathering, preserving, and sharing genealogical records from around the world.
I’m so lucky I get to speak with all of these folks about the benefits, and perils of APIs, helping them think through their approach to opening up their valuable resources using APIs. The process is nourishing for me because I get to speak to such a diverse number of implementations, push my understanding of what is possible with APIs, while also sharpening my critical eye, understanding of where APIs can help, or where they can possibly go wrong. Personally, I find a couple of things very intriguing about the Family Search API story:
- Mapping the worlds genealogical history using a publicly available API — Going Big!!
- Potential from participation by not just big partners, but the long tail of genealogical geeks
- Transparency, openness, and collaboration shining through as the solution beyond just the technology
- The mission driven focus of the API overlapping with my obsession for API evangelism intrigues and scares me
- Have existing developer area, APIs, and seemingly necessary building blocks but failed to achieve a platform level
I’m open to talking with anyone about their startup, SMB, enterprise, organizational, institutional, or government API, always leaving open a 15 minute slot to hear a good story, which turned into more than an hour of discussion with the Family Search team. See, Family Search already has an API, they have the technology in order, and they even have many of the essential business building blocks as well, but where they are falling short is when it comes to dialing in both the business and politics of their developer ecosystem to discover the right balance that will help them truly become a platform—which is my specialty. ;-)
This brings us to the million dollar question: How does one become a platform?
All of this makes Family Search an interesting API story. The scope of the API, and to take something this big to the next level, Family Search has to become a platform, and not a superficial “platform” where they are just catering to three partners, but nourishing a vibrant long tail ecosystem of website, web application, single page application, mobile applications, and widget developers. Family Search is at an important reflection point, they have all the parts and pieces of a platform, they just have to figure out exactly what changes need to be made to open up, and take things to the next level.
First, let’s quantify the company, what is FamilySearch? “ For over 100 years, FamilySearch has been actively gathering, preserving, and sharing genealogical records worldwide”, believing that “learning about our ancestors helps us better understand who we are—creating a family bond, linking the present to the past, and building a bridge to the future”.
FamilySearch is 1.2 billion total records, with 108 million completed in 2014 so far, with 24 million awaiting, as well as 386 active genealogical projects going on. Family Search provides the ability to manage photos, stories, documents, people, and albums—allowing people to be organized into a tree, knowing the branch everyone belongs to in the global family tree.
FamilySearch, started out as the Genealogical Society of Utah, which was founded in 1894, and dedicate preserving the records of the family of mankind, looking to "help people connect with their ancestors through easy access to historical records”. FamilySearch is a mission-driven, non-profit organization, ran by the The Church of Jesus Christ of Latter-day Saints. All of this comes together to define an entity, that possesses an image that will appeal to some, while leave concern for others—making for a pretty unique formula for an API driven platform, that doesn’t quite have a model anywhere else.
FamilySearch consider what they deliver as as a set of record custodian services:
- Image Capture - Obtaining a preservation quality image is often the most costly and time-consuming step for records custodians. Microfilm has been the standard, but digital is emerging. Whether you opt to do it yourself or use one of our worldwide camera teams, we can help.
- Online Indexing - Once an image is digitized, key data needs to be transcribed in order to produce a searchable index that patrons around the world can access. Our online indexing application harnesses volunteers from around the world to quickly and accurately create indexes.
- Digital Conversion - For those records custodians who already have a substantial collection of microfilm, we can help digitize those images and even provide digital image storage.
- Online Access - Whether your goal is to make your records freely available to the public or to help supplement your budget needs, we can help you get your records online. To minimize your costs and increase access for your users, we can host your indexes and records on FamilySearch.org, or we can provide tools and expertise that enable you to create your own hosted access.
- Preservation - Preservation copies of microfilm, microfiche, and digital records from over 100 countries and spanning hundreds of years are safely stored in the Granite Mountain Records Vault—a long-term storage facility designed for preservation.
FamilySearch provides a proven set of services that users can take advantage of via a web applications, as well as iPhone and Android mobile apps, resulting in the online community they have built today. FamilySearch also goes beyond their basic web and mobile application services, and is elevated to software as a service (SaaS) level by having a pretty robust developer center and API stack.
FamilySearch provides the required first impression when you land in the FamilySearch developer center, quickly explaining what you can do with the API, "FamilySearch offers developers a way to integrate web, desktop, and mobile apps with its collaborative Family Tree and vast digital archive of records”, and immediately provides you with a getting started guide, and other supporting tutorials.
FamilySearch provides access to over 100 API resources in the twenty separate groups: Authorities, Change History, Discovery, Discussions, Memories, Notes, Ordinances, Parents and Children, Pedigree, Person, Places, Records, Search and Match, Source Box, Sources, Spouses, User, Utilities, Vocabularies, connecting you to the core FamilySearch genealogical engine.
The FamilySearch developer area provides all the common, and even some forward leaning technical building blocks:
To support developers, FamilySearch provides a fairly standard support setup:
To augment support efforts there are also some other interesting building blocks:
Setting the stage for FamilySearch evolving to being a platform, they even posses some necessary partner level building blocks:
There is even an application gallery showcasing what web, mac & windows desktop, and mobile applications developers have built. FamilySearch even encourages developers to “donate your software skills by participating in community projects and collaborating through the FamilySearch Developer Network”.
Many of the ingredients of a platform exist within the current FamilySearch developer hub, at least the technical elements, and some of the common business, and political building blocks of a platform, but what is missing? This is what makes FamilySearch a compelling story, because it emphasizes one of the core elements of API Evangelist—that all of this API stuff only works when the right blend of technical, business, and politics exists.
Establishing A Rich Partnership Environment
FamilySearch has some strong partnerships, that have helped establish FamilySearch as the genealogy service it is today. FamilySearch knows they wouldn’t exist without the partnerships they’ve established, but how do you take it to the next and grow to a much larger, organic API driven ecosystem where a long tail of genealogy businesses, professionals, and enthusiasts can build on, and contribute to, the FamilySearch platform.
FamilySearch knows the time has come to make a shift to being an open platform, but is not entirely sure what needs to happen to actually stimulate not just the core FamilySearch partners, but also establish a vibrant long tail of developers. A developer portal is not just a place where geeky coders come to find what they need, it is a hub where business development occurs at all levels, in both synchronous, and asynchronous ways, in a 24/7 global environment.
FamilySearch acknowledge they have some issues when it comes investing in API driven partnerships:
- “Platform” means their core set of large partners
- Not treating all partners like first class citizens
- Competing with some of their partners
- Don’t use their own API, creating a gap in perspective
FamilySearch knows if they can work out the right configuration, they can evolve FamilySearch from a digital genealogical web and mobile service to a genealogical platform. If they do this they can scale beyond what they’ve been able to do with a core set of partners, and crowdsource the mapping of the global family tree, allowing individuals to map their own family trees, while also contributing to the larger global tree. With a proper API driven platform this process doesn’t have to occur via the FamiliySearch website and mobile app, it can happen in any web, desktop, or mobile application anywhere.
FamilySearch already has a pretty solid development team taking care of the tech of the FamilySearch API, and they have 20 people working internally to support partners. They have a handle on the tech of their API, they just need to get a handle on the business and politics of their API, and invest in the resources that needed to help scale the FamilySearch API being just a developer area, to being a growing genealogical developer community, to a full blow ecosystem that span not just the FamilySearch developer portal, but thousands of other sites and applications around the globe.
A Good Dose Of API Evangelism To Shift Culture A Bit
A healthy API evangelism strategy brings together a mix of business, marketing, sales and technology disciplines into a new approach to doing business for FamilySearch, something that if done right, can open up FamilySearch to outside ideas, and with the right framework manage to allow the platform to move beyond just certification, and partnering to also investment, and acquisition of data, content, talent, applications, and partners via the FamilySearch developer platform.
Think of evangelism as the grease in the gears of the platform allowing it to grow, expand, and handle a larger volume, of outreach, and support. API evangelism works to lubricate all aspects of platform operation.
First, lets kick off with setting some objectives for why we are doing this, what are we trying to accomplish:
- Increase Number of Records - Increase the number of overall records in the FamilySearch database, contributing the larger goals of mapping the global family tree.
- Growth in New Users - Growing the number of new users who are building on the FamilySearch API, increase the overall headcount fro the platform.
- Growth In Active Apps - Increase not just new users but the number of actual apps being built and used, not just counting people kicking the tires.
- Growth in Existing User API Usage - Increase how existing users are putting the FamilySearch APIs. Educate about new features, increase adoption.
- Brand Awareness - One of the top reasons for designing, deploying and managing an active APIs is increase awareness of the FamilySearch brand.
- What else?
What does developer engagement look like for the FamilySearch platform?
- Active User Engagement - How do we reach out to existing, active users and find out what they need, and how do we profile them and continue to understand who they are and what they need. Is there a direct line to the CRM?
- Fresh Engagement - How is FamilySearch contacting new developers who have registered weekly to see what their immediate needs are, while their registration is fresh in their minds.
- Historical Engagement - How are historical active and / or inactive developers being engaged to better understand what their needs are and would make them active or increase activity.
- Social Engagement - Is FamilySearch profiling the URL, Twitter, Facebook LinkedIn, and Github profiles, and then actively engage via these active channels?
Establish a Developer Focused Blog For Storytelling
- Projects - There are over 390 active projects on the FamilySearch platform, plus any number of active web, desktop, and mobile applications. All of this activity should be regularly profiled as part of platform evangelism. An editorial assembly line of technical projects that can feed blog stories, how-tos, samples and Github code libraries should be taking place, establishing a large volume of exhaust via the FamlySearch platform.
- Stories - FamilySearch is great at writing public, and partner facing content, but there is a need to be writing, editing and posting of stories derived from the technically focused projects, with SEO and API support by design.
- Syndication - Syndication to Tumblr, Blogger, Medium and other relevant blogging sites on regular basis with the best of the content.
Mapping Out The Geneology Landscape
- Competition Monitoring - Evaluation of regular activity of competitors via their blog, Twitter, Github and beyond.
- Alpha Players - Who are the vocal people in the genealogy space with active Twitter, blogs, and Github accounts.
- Top Apps - What are the top applications in the space, whether built on the FamilySearch platform or not, and what do they do?
- Social - Mapping the social landscape for genealogy, who is who, and who should the platform be working with.
- Keywords - Established a list of keywords to use when searching for topics at search engines, QA, forums, social bookmarking and social networks. (should already be done by marketing folks)
- Cities & Regions - Target specific markets in cities that make sense to your evangelism strategy, what are local tech meet ups, what are the local organizations, schools, and other gatherings. Who are the tech ambassadors for FamilySearch in these spaces?
Adding To Feedback Loop From Forum Operations
- Stories - Deriving of stories for blog derived from forum activity, and the actual needs of developers.
- FAQ Feed - Is this being updated regularly with stuff?
- Streams - other stream giving the platform a heartbeat?
Being Social About Platform Code and Operations With Github
- Setup Github Account - Setup FamilySearch platform developer account and bring internal development team into a team umbrella as part of.
- Github Relationships - Managing of followers, forks, downloads and other potential relationships via Github, which has grown beyond just code, and is social.
- Github Repositories - Managing of code sample Gists, official code libraries and any samples, starter kits or other code samples generated through projects.
Adding To The Feedback Loop From The Bigger FAQ Picture
- Quora - Regular trolling of Quora and responding to relevant [Client Name] or industry related questions.
- Stack Exchange - Regular trolling of Stack Exchange / Stack Overflow and responding to relevant FamilySearch or industry related questions.
- FAQ - Add questions from the bigger FAQ picture to the local FamilySearch FAQ for referencing locally.
Leverage Social Engagement And Bring In Developers Too
- Facebook - Consider setting up of new API specific Facebook company. Posting of all API evangelism activities and management of friends.
- Google Plus - Consider setting up of new API specific Google+ company. Posting of all API evangelism activities and management of friends.
- LinkedIn - Consider setting up of new API specific LinkedIn profile page who will follow developers and other relevant users for engagement. Posting of all API evangelism activities.
- Twitter - Consider setting up of new API specific Twitter account. Tweeting of all API evangelism activity, relevant industry landscape activity, discover new followers and engage with followers.
Sharing Bookmarks With the Social Space
- Hacker News - Social bookmarking of all relevant API evangelism activities as well as relevant industry landscape topics to Hacker News, to keep a fair and balanced profile, as well as network and user engagement.
- Product Hunt - Product Hunt is a place to share the latest tech creations, providing an excellent format for API providers to share details about their new API offerings.
- Reddit - Social bookmarking of all relevant API evangelism activities as well as relevant industry landscape topics to Reddit, to keep a fair and balanced profile, as well as network and user engagement.
Communicate Where The Roadmap Is Going
- Roadmap - Provide regular roadmap feedback based upon developer outreach and feedback.
- Changelog - Make sure the change log always reflects the roadmap communication or there could be backlash.
Establish A Presence At Events
- Conferences - What are the top conferences occurring that we can participate in or attend--pay attention to call for papers of relevant industry events.
- Hackathons - What hackathons are coming up in 30, 90, 120 days? Which would should be sponsored, attended, etc.
- Meetups - What are the best meetups in target cities? Are there different formats that would best meet our goals? Are there any sponsorship or speaking opportunities?
- Family History Centers - Are there local opportunities for the platform to hold training, workshops and other events at Family History Centers?
- Learning Centers - Are there local opportunities for the platform to hold training, workshops and other events at Learning Centers?
Measuring All Platform Efforts
- Activity By Group - Summary and highlights from weekly activity within the each area of API evangelism strategy.
- New Registrations - Historical and weekly accounting of new developer registrations across APis.
- Volume of Calls - Historical and weekly accounting of API calls per API.
- Number of Apps - How many applications are there.
Essential Internal Evangelism Activities
- Storytelling - Telling stories of an API isn’t just something you do externally, what stories need to be told internally to make sure an API initiative is successful.
- Conversations - Incite internal conversations about the FamilySearch platform. Hold brown bag lunches if you need to, or internal hackathons to get them involved.
- Participation - It is very healthy to include other people from across the company in API operations. How can we include people from other teams in API evangelism efforts. Bring them to events, conferences and potentially expose them to local, platform focused events.
- Reporting - Sometimes providing regular numbers and reports to key players internally can help keep operations running smooth. What reports can we produce? Make them meaningful.
All of this evangelism starts with a very external focus, which is a hallmark of API and developer evangelism efforts, but if you notice by the end we are bringing it home to the most important aspect of platform evangelism, the internal outreach. This is the number one reason APIs fail, is due to a lack of internal evangelism, educating top and mid-level management, as well as lower level staff, getting buy-in and direct hands-on involvement with the platform, and failing to justify budget costs for the resources needed to make a platform successful.
Top-Down Change At FamilySearch
The change FamilySearch is looking for already has top level management buy-in, the problem is that the vision is not in lock step sync with actual platform operations. When regular projects developed via the FamilySearch platform are regularly showcased to top level executives, and stories consistent with platform operations are told, management will echo what is actually happening via the FamilySearch. This will provide a much more ongoing, deeper message for the rest of the company, and partners around what the priorities of the platform are, making it not just a meaningless top down mandate.
An example of this in action is with the recent mandate from President Obama, that all federal agencies should go “machine readable by default”, which includes using APIs and open data outputs like JSON, instead of document formats like PDF. This top down mandate makes for a good PR soundbite, but in reality has little affect on the ground at federal agencies. In reality it has taken two years of hard work on the ground, at each agency, between agencies, and with the public to even begin to make this mandate a truth at over 20 of the federal government agencies.
Top down change is a piece of the overall platform evolution at FamilySearch, but is only a piece. Without proper bottom-up, and outside-in change, FamilySearch will never evolve beyond just being a genealogical software as a service with an interesting API. It takes much more than leadership to make a platform.
Bottom-Up Change At FamilySearch
One of the most influential aspects of APIs I have seen at companies, institutions, and agencies is the change of culture brought when APIs move beyond just a technical IT effort, and become about making resources available across an organization, and enabling people to do their job better. Without an awareness, buy-in, and in some cases evangelist conversion, a large organization will not be able to move from a service orientation to a platform way of thinking.
If a company as a whole is unaware of APIs, either at the company or organization, as well as out in the larger world with popular platforms like Twitter, Instagram, and others—it is extremely unlikely they will endorse, let alone participate in moving from being a digital service to platform. Employees need to see the benefits of a platform to their everyday job, and their involvement cannot require what they would perceive as extra work to accomplish platform related duties. FamilySearch employees need to see the benefits the platform brings to the overall mission, and play a role in this happening—even if it originates from a top-down mandate.
Top bookseller Amazon was already on the path to being a platform with their set of commerce APIs, when after a top down mandate from CEO Jeff Bezos, Amazon internalized APIs in such a way, that the entire company interacted, and exchange resources using web APIs, resulting in one of the most successful API platforms—Amazon Web Services (AWS). Bezos mandated that if an Amazon department needed to procure a resource from another department, like server or storage space from IT, it need to happen via APIs. This wasn’t a meaningless top-down mandate, it made employees life easier, and ultimately made the entire company more nimble, and agile, while also saving time and money. Without buy-in, and execution from Amazon employees, what we know as the cloud would never have occurred.
Change at large enterprises, organizations, institutions and agencies, can be expedited with the right top-down leadership, but without the right platform evangelism strategy, that includes internal stakeholders as not just targets of outreach efforts, but also inclusion in operations, it can result in sweeping, transformational changes. This type of change at a single organization can effect how an entire industry operates, similar to what we’ve seen from the ultimate API platform pioneer, Amazon.
Outside-In Change At FamilySearch
The final layer of change that needs to occur to bring FamilySearch from being just a service to a true platform, is opening up the channels to outside influence when it comes not just to platform operations, but organizational operations as well. The bar is high at FamilySearch. The quality of services, and expectation of the process, and adherence to the mission is strong, but if you are truly dedicated to providing a database of all mankind, you are going to have to let mankind in a little bit.
FamilySearch is still the keeper of knowledge, but to become a platform you have to let in the possibility that outside ideas, process, and applications can bring value to the organization, as well as to the wider genealogical community. You have to evolve beyond notions that the best ideas from inside the organization, and just from the leading partners in the space. There are opportunities for innovation and transformation in the long-tail stream, but you have to have a platform setup to encourage, participate in, and be able to identify value in the long-tail stream of an API platform.
Twitter is one of the best examples of how any platform will have to let in outside ideas, applications, companies, and individuals. Much of what we consider as Twitter today was built in the platform ecosystem from the iPhone and Android apps, to the desktop app TweetDeck, to terminology like the #hashtag. Over the last 5 years, Twitter has worked hard to find the optimal platform balance, regarding how they educate, communicate, invest, acquire, and incentives their platform ecosystem. Listening to outside ideas goes well beyond the fact that Twitter is a publicly available social platform, it is about having such a large platform of API developers, and it is impossible to let in all ideas, but through a sophisticated evangelism strategy of in-person, and online channels, in 2014 Twitter has managed to find a balance that is working well.
Having a public facing platform doesn’t mean the flood gates are open for ideas, and thoughts to just flow in, this is where service composition, and the certification and partner framework for FamilySearch will come in. Through clear, transparent partners tiers, open and transparent operations and communications, an optimal flow of outside ideas, applications, companies and individuals can be established—enabling a healthy, sustainable amount of change from the outside world.
Knowing All Of Your Platform Partners
The hallmark of any mature online platform is a well established partner ecosystem. If you’ve made the transition from service to platform, you’ve established a pretty robust approach to not just certifying, and on boarding your partners, you also have stepped it up in knowing and understanding who they are, what their needs are, and investing in them throughout the lifecycle.
First off, profile everyone who comes through the front door of the platform. If they sign up for a public API key, who are they, and where do they potentially fit into your overall strategy. Don’t be pushy, but understanding who they are and what they might be looking for, and make sure you have a track for this type of user well defined.
Next, quality, and certify as you have been doing. Make sure the process is well documented, but also transparent, allowing companies and individuals to quickly understand what it will take to certified, what the benefits are, and examples of other partners who have achieved this status. As a developer, building a genealogical mobile app, I need to know what I can expect, and have some incentive for investing in the certification process.
Keep your friends close, and your competition closer. Open the door wide for your competition to become a platform user, and potentially partner. 100+ year old technology company Johnson Controls (JCI) was concerned about what the competition might do it they opened up their building efficient data resources to the public via the Panoptix API platform, when after it was launched, they realized their competition were now their customer, and a partner in this new approach to doing business online for JCI.
When Department of Energy decides what data and other resource it makes available via Data.gov or the agencies developer program it has to deeply consider how this could affect U.S. industries. The resources the federal agency possesses can be pretty high value, and huge benefits for the private sector, but in some cases how might opening up APIs, or limiting access to APIs help or hurt the larger economy, as well as the Department of Energy developer ecosystem—there are lots of considerations when opening up API resources, that vary from industry to industry.
There are no silver bullets when it comes to API design, deployment, management, and evangelism. It takes a lot of hard work, communication, and iterating before you strike the right balance of operations, and every business sector will be different. Without knowing who your platform users are, and being able to establish a clear and transparent road for them to follow to achieve partner status, FamilySearch will never elevate to a true platform. How can you scale the trusted layers of your platform, if your partner framework isn’t well documented, open, transparent, and well executed? It just can’t be done.
Meaningful Monetization For Platform
All of this will take money to make happen. Designing, and executing on the technical, and the evangelism aspects I’m laying out will cost a lot of money, and on the consumers side, it will take money to design, develop, and manage desktop, web, and mobile applications build around the FamilySearch platform. How will both the FamilySearch platform, and its participants make ends meet?
This conversation is a hard one for startups, and established businesses, let alone when you are a non-profit, mission driven organization. Internal developers cost money, server and bandwidth are getting cheaper but still are a significant platform cost--sustaining a sale, bizdev, and evangelism also will not be cheap. It takes money to properly deliver resources via APIs, and even if the lowest tiers of access are free, at some point consumers are going to have to pay for access, resources, and advanced features.
The conversation around how do you monetize API driven resources is going on across government, from cities up to the federal government. Where the thought of charging for access to public data is unheard of. These are public assets, and they should be freely available. While this is true, think of the same situation, but when it comes to physical public assets that are owned by the government, like parks. You can freely enjoy many city, county, and federal parks, there are sometimes small fees for usage, but if you want to actually sell something in a public park, you will need to buy permits, and often share revenue with the managing agency. We have to think critically about how we fund the publishing, and refinement of publicly owned digital assets, as with physical assets there will be much debate in coming years, around what is acceptable, and what is not.
Woven into the tiers of partner access, there should always be provisions for applying costs, overhead, and even generation of a little revenue to be applied in other ways. With great power, comes great responsibility, and along with great access for FamilySearch partners, many will also be required to cover costs of compute capacity, storage costs, and other hard facts of delivering a scalable platform around any valuable digital assets, whether its privately or publicly held.
Platform monetization doesn’t end with covering the costs of platform operation. Consumers of FamilySearch APIs will need assistance in identify the best ways to cover their own costs as well. Running a successful desktop, web or mobile application will take discipline, structure, and the ability to manage overhead costs, while also being able to generate some revenue through a clear business model. As a platform, FamilySearch will have to bring to the table some monetization opportunities for consumers, providing guidance as part of the certification process regarding what are best practices for monetization, and even some direct opportunities for advertising, in-app purchases and other common approaches to application monetization and sustainment.
Without revenue greasing the gears, no service can achieve platform status. As with all other aspects of platform operations the conversation around monetization cannot be on-sided, and just about the needs of the platform providers. Pro-active steps need to be taken to ensure both the platform provider, and its consumers are being monetized in the healthiest way possible, bringing as much benefit to the overall platform community as possible.
Open & Transparent Operations & Communications
How does all of this talk of platform and evangelism actually happen? It takes a whole lot of open, transparent communication across the board. Right now the only active part of the platform is the FamilySearch Developer Google Group, beyond that you don’t see any activity that is platform specific. There are active Twitter, Facebook, Google+, and mainstream and affiliate focused blogs, but nothing that serves the platform, contributed to the feedback loop that will be necessary to take the service to the next level.
On a public platform, communications cannot all be private emails, phone calls, or face to face meetings. One of the things that allows an online service to expand to become a platform, then scale and grow into robust, vibrant, and active community is a stream of public communications, which include blogs, forums, social streams, images, and video content. These communication channels cannot all be one way, meaning they need to include forum and social conversations, as well as showcase platform activity by API consumers.
Platform communications isn’t just about getting direct messages answered, it is about public conversation so everyone shares in the answer, and public storytelling to help guide and lead the platform, that together with support via multiple channels, establishes a feedback loop, that when done right will keep growing, expanding and driving healthy growth. The transparent nature of platform feedback loops are essential to providing everything the consumers will need, while also bringing a fresh flow of ideas, and insight within the FamilySearch firewall.
Truly Shifting FamilySearch The Culture
Top-down, bottom-up, outside-in, with constantly flow of oxygen via vibrant, flowing feedback loop, and the nourishing, and sanitizing sunlight of platform transparency, where week by week, month by month someone change can occur. It won’t all be good, there are plenty of problems that arise in ecosystem operations, but all of this has the potential to slowly shift culture when done right.
One thing that shows me the team over at FamilySearch has what it takes, is when I asked if I could write this up a story, rather than just a proposal I email them, they said yes. This is a true test of whether or not an organization might have what it takes. If you are unwilling to be transparent about the problems you have currently, and the work that goes into your strategy, it is unlikely you will have what it takes to establish the amount of transparency required for a platform to be successful.
When internal staff, large external partners, and long tail genealogical app developers and enthusiasts are in sync via a FamilySearch platform driven ecosystem, I think we can consider a shift to platform has occurred for FamilySearch. The real question is how do we get there?
Executing On Evangelism
This is not a definitive proposal for executing on an API evangelism strategy, merely a blueprint for the seed that can be used to start a slow, seismic shift in how FamilySearch engages its API area, in a way that will slowly evolve it into a community, one that includes internal, partner, and public developers, and some day, with the right set of circumstances, FamilySearch could grow into robust, social, genealogical ecosystem where everyone comes to access, and participate in the mapping of mankind.
- Defining Current Platform - Where are we now? In detail.
- Mapping the Landscape - What does the world of genealogy look like?
- Identifying Projects - What are the existing projects being developed via the platform?
- Define an API Evangelist Strategy - Actually flushing out of a detailed strategy.
- External Public
- External Partner
- Internal Stakeholder
- Internal Company-Wide
- Identify Resources - What resource currently exist? What are needed?
- Content / Storytelling
- Execute - What does execution of an API evangelist strategy look like?
- Iterate - What does iteration look like for an API evangelism strategy.
AS with many providers, you don’t want to this to take 5 years, so how do you take a 3-5 year cycle, and execute in 12-18 months?
- Invest In Evangelist Resources - It takes a team of evangelists to build a platform
- External Facing
- Partner Facing
- Internal Facing
- Development Resources - We need to step up the number of resources available for platform integration.
- Code Samples & SDKs
- Embeddable Tools
- Content Resources - A steady stream of content should be flowing out of the platform, and syndicated everywhere.
- Short Form (Blog)
- Long Form (White Paper & Case Study)
- Event Budget - FamilySearch needs to be everywhere, so people know that it exists. It can’t just be online.
There is nothing easy about this. It takes time, and resources, and there are only so many elements you can automate when it comes to API evangelism. For something that is very programmatic, it takes more of the human variable to make the API driven platform algorithm work. With that said it is possible to scale some aspects, and increase the awareness, presence, and effectiveness of FamilySearch platform efforts, which is really what is currently missing.
While as the API Evangelist, I cannot personally execute on every aspect of an API evangelism strategy for FamilySearch, I can provide essential planning expertise for the overall FamilySearch API strategy, as well as provide regular checkin with the team on how things are going, and help plan the roadmap. The two things I can bring to the table that are reflected in this proposal, is the understanding of where the FamilySearch API effort currently is, and what is missing to help get FamilySearch to the next stage of its platform evolution.
When operating within the corporate or organizational silo, it can be very easy to lose site of how other organizations, and companies, are approach their API strategy, and miss important pieces of how you need to shift your strategy. This is one of the biggest inhibitors of API efforts at large organizations, and is one of the biggest imperatives for companies to invest in their API strategy, and begin the process of breaking operations out of their silo.
What FamilySearch is facing demonstrates that APIs are much more than the technical endpoint that most believe, it takes many other business, and political building blocks to truly go from API to platform.
I spoke with the leading financial data API aggregation providers Yodlee last week, regarding their hunt for a director of developer evangelism. Yodlee provides an aggregation API that is designed for developers who need secure access to their users’ bank, credit card, investment, and loan accounts—if you think about it, this is a pretty critical API, in what we are all calling the “API Economy”.
Yodlee isn’t just looking for a junior evangelist, they are looking for a director—someone to lead the charge, when it comes to evangelizing Yodlee to potential API consumers, while also supporting the community and applications that are already integrated with the financial data aggregation platform. While there are well published job descriptions for the API evangelist role, there are no universities training up, cranking out the next generation of evangelism leaders—they are a unique breed, leaving a major hurdle for API providers like Yodlee to jump.
Evangelists are equal parts engineer, business development, product development, sales, and marketing—a combination that is not easy to find. Yodlee and I discussed the difficulties of finding the right candidates for the role, and whether or not you emphasize the technical or the marketing skills? There are extremely few candidates who know they are evangelist material, you often have to sculpt one out of many different personality traits, and both technical and business skils.
Evangelism talent, at both junior, and leadership levels is going to continue to be a major stumbling block for the expanding API economy. Even with some movement in the world of API discovery in 2014, we will never be able to fully automate API discovery, let alone evangelism, management and support. At some point we are going to need more agencies, and institutions focusing on training up the next generation of evangelists, similar to social media marketing did in the last 5 years—of course, hopefully we can scale a little more sensibly, than the social media marketing world did.
If you are interested in the developer evangelist position at Yodlee, head over to the recruiters site, and let them know I sent you.
I’m playing with a new tool that was brought to my attention called, the Small Federated Wiki (SFW), a dead-simple, yet powerfully extensible, and federated online platform solution, developed by Mike Cauffield. In his latest post about Smallest Federated Wiki as a Universal JSON Canvas, Mike opens up with a story of how hard tech evangelism is, with an example from Xerox PARC:
Watching Alan Kay talk today about early Xerox PARC days was enjoyable, but also reminded me how much good ideas need advocating. As Kay pointed out repeatedly, explaining truly new ways of doing things is hard.
First, without Mike’s continue storytelling around his work, it wouldn’t continue to float up on my task list. His story about it being a “Universal JSON Canvas”, caught my attention, lit a spark that trumped the shitload of other work I should be doing this morning. Evangelism is hard. Evangelism is tedious. Evangelism requires constant storytelling, in real-time.
Second, for the Smallest Federated Wiki (SFW) to be successful, evangelism will have to be baked in. I will be playing with this concept more, to produce demonstrable versions, but SFW + Docker Containers, will allow for a new world of application collaboration. The Amazons, Googles, and Microsofts of the world are taking popular open source platform combinations like Wordpress, and Drupal, creating container definitions that include Linux, PHP, MySQL and other platform essentials, that can be easily deployed in any environment—now think about the potential of SWF + Docker.
Following this new container pattern, I can build out small informational wikis using SWF, add on plugins, either standard or custom, and create a specific implementation of SWF, which I can deploy as a container definition with underlying linux, node.js, and other required platform essentials. This will allow me to tailor specific SWF blueprints, that anyone else can deploy with the push of a button. Think courseware, research, curation, and other collaborative classroom application scenarios--I can establish a base SFW template, and let someone else run with the actual implementation.
Now, bringing this back home to evangelism--Mike doesn’t have to run around explaining to everyone what SFW does, well he should be, but not to EVERYONE. People who care about specific domains, can build SFW blueprints, utilize containers on Amazon, Google, Microsoft and other providers to deploy blueprints, and through evangelizing their own SFW implementations, will evangelism what SFW is capable of, to other practitioners--federated evangelism baked in too! ;-)
The federation of evangelism, will be how the Smallest Federated Wiki spreads like a virus.
I’m working with the Cashtie API to pull together an API evangelism strategy for the payments API. As I pull together, it seems like a great opportunity to share with you. Who knows, maybe you can use some of the elements in your own API strategy.
Next up is what I call "landscape analysis", which is about monitoring the blogs, and other social network activity of the sector(s) you are evangelizing your API within:
- Competition Monitoring - Evaluation of regular the activity of competitors, visiting their sites, and getting to know their customers.
- Industry Monitoring - Evaluation of relevant topics and trends of overall industry, industries that you are evangelizing within.
- Keywords - Established a list of keywords to use when searching for topics at search engines, QA, forums, social bookmarking and social networks—this should dovetail nicely into any SEO work your doing. You are doing SEO work?
- City and Country Targeting - Target specific markets with your evangelism. Get to know where your existing developers and target developers reside, and get local--be on the ground.
- Social Media Monitoring - Have a solid strategy and platform for pulling relevant data from Twitter accounts, #hashtag conversations, Github profiles, and other relevant platforms to use in your landscape analysis.
The "landscape", is the space you are looking at each and every day out your virtual window, as well as what your existing and target developers will see each day. It is your job as an evangelist or advocate to know this space well, understand all the elements of the landscape, key players, relationships, and be a contributing member to this landscape.
Lanscape analysis should be something you do every day, weaving it into your regular social media, and other online activities. Remember you aren’t targeting this landscape of companies and users, you are looking to participate in the conversation, while also bring your API resources to the table.
I’m working with the Cashtie API to pull together an API evangelism strategy for the payments API. As I pull together, it seems like a great opportunity to share with you. Who knows, maybe you can use some of the elements in your own API strategy.
Next up is blogging, an area I feel is the single most important part of your API evangelism strategy:
- Projects - Establishing of editorial assembly line of technical projects that can feed blog stories, how-tos, samples and code libraries.
- Stories - Writing, editing and posting of stories derived from projects, with SEO and API area support by design.
- Syndication - Syndication to Tumblr, Blogger and other relevant blogging sites that actually add value to readers, not being spammy.
This part of evangelism can be as involved as you like, being the work of a lone evangelist, or the work of a team of coders, writers, editors and community managers. The goal is to generate exhaust around your API, that will attract new developers to an API, as well as educate existing developers about the value an API delivers.
If you aren’t producing interesting projects around your API, and telling these stories far and wide, nobody will ever know your API exists, let alone put it to use.
I’m working with the Cashtie API to pull together an API evangelism strategy for the payments API. As I pull together, it seems like a great opportunity to share with you. Who knows, maybe you can use some of the elements in your own API strategy.
Next up is developer engagement, and focusing on the ways you reach out to API consumers. You don’t need to describe every way you are going to engage with developers, but you should make sure and pick a handful of channels and stick with them, regularly reaching out to developers, providing a communication platform they can depend on.
There are some proven approaches to developer outreach:
- Fresh Engagement - Emailing new developers who have registered to see what their immediate needs are, while their registration is fresh in their minds
- Active User Engagement - Reaching out to existing, active users of an API and find out what they need. Profile them, including Twitter, Facebook, LinkedIn and pull any profile information, then grade and categorize each developer
- Historical Engagement - Emailing historical active and / or inactive developers to engage and understand what their needs are and would make them active or increase activity, consider newsletter or personalized emails when appropriate
- Social Engagement - When emailing any developer, using Rapportive you can establish any URL, Twitter, Facebook or LinkedIn profile they have and reach out via these networks
There are many other ways to reach out to developers, but you should have a regular rhythm for reaching out to new developers, existing developers will re-enforce relationships with your developers consistently through the channels that make the most sense.
If developers know they will get regularly information from you via a newsletter, and that you are accessible via common social media channels, they are more likely to reach out when they need help, and have you in the back of their mind when they do encounter a problem that your API provides a solution to.
I’m working with the Cashtie API to pull together API evangelism strategy for the payments API. As I pull together it seems like a great opportunity to share with you. Who knows, maybe you can use some of the elements in your own API strategy.
First up, is goals. What are the goals of your API initiative?
- Increase Awareness of API Program - The number one priority for any API, increase awareness that you even exist!
- Growth in New Users - Everyone wants new registrations for the API--it s a great goal, but don’t get too caught up in just acquiring new users.
- Growth in Existing User API Usage - How do we encourage existing users to consume more, be more successful in using API resources.
- Brand Awareness - Elevate the awareness of not just an API but the overall company brand(s), establishing life long customers.
These are just a few initial goals every company should consider when crafting an API evangelism campaign, but don’t stop there, what are some other goals?
- New Customers For Other Products - Do you have other products and services you’d like your API end-users to be aware of?
- Value Add For Existing Customers - Maybe you have an existing customer base you want to encourage development of products, services and features that add value to their existing engagement.
- Revenue - Money, of course, we all need to make money. How do we leverage API resources into new sources of revenue for our company?
Having short term, and long term goals is essential to any API evangelism strategy. What are our long term goals? What goals do we have this week? How do they change over time? Documenting our goals is critical, so we can deliver on them, but also understand how we need to shift our goals to be more successful over time.
Do you have goals for your API program that aren't listed here? Share them with me on Twitter @kinlane with hashtag #apigoals.
I just had a great conversion with John Bernd (@jkbernd) and Simone Vigano (@viganosimone) of Johnson Controls (JCI), who lead efforts at the building efficiency API, Panoptix. They shared several great stories with me, I’ll trickle out over the next week, with the first one about internal evangelism.
Internal evangelism, whether your API is public or private, is something I’ve advocated for pretty heavily over the last few years. Lack of internal evangelism around an API can be the number on reason you get your API defunded within any size organization. Basically if the rest of the company, included your bosses , don’t know about your API and the success you’ve had, your done. So tell stories about your API.
This particular story out of JCI is particularly interesting because it isn’t just about evangelizing your API, its evangelizing your approach to delivering your API. Over the last couple years of the Panoptix API, John and Simone have done a great job evangelizing the Panoptix API internally (separate story coming soon), but somehow in the hustle they forgot to package up and sell their approach to delivering the Panoptix API, so other groups within JCI can learn about and put the API approach to use for their own needs.
Panoptix realized they need to document their own approach to designing, developing, deploying and managing the Panoptix API, create a case study that they can then evangelize within JCI. The benefits of separating data and resources, establishing self-service APIs, establishing meaningful metrics combined with analytics, and the overall health brought by an API centric approach, was something that every group within JCI needs to understand. Panoptix uses 3Scale API infrastructure, and has been reading API Evangelist for a couple years, resulting in their own unique approach to API delivery, you can experience within the Panoptix developer community.
Hearing John and Simone talk through their realization, made me see another layer to internal API evangelism. You shouldn’t just have a coherent API design, deployment, management and evangelism strategy so that you can execute on it, you should have one so that you can clearly articulate it to the rest of your company and help onboard them with your API centric approach to getting things done.
Disclosure: 3Scale is an API Evangelist partner
An API is useless if nobody knows about it. Evangelism has emerged as the approach to selling, marketing and support an API platform. While the intent of evangelism can be sales and marketing, the philosophy that has proved successful is to find a balance that is more about focusing on API support and engagement with consumers over sales.
A healthy API evangelism strategy brings together a mix of business, marketing, sales and technology disciplines into a new approach to doing business.
Healthy API evangelism is centered around clear goals. Goals usually start with targets like new user registration, but need to be set higher around active API consumers, expanding how your existing users consume your API resources, all the way to clear definition of how your API will extend and expand your brand.
While it may seem obvious, actively engaging API consumers often gets lost in the shuffle. Have a strategic approach to reaching out to new users in a meaningful way, establishing healthy practices for reaching out to existing developers at various stages of integration, is essential to growing an API initiative. Without planned engagement of API consumers, a canyon will grow between API provider and API consumer, one that may never be able to be reversed.
An active blog, with an RSS feed has the potential to be the face of an API and developer evangelism campaign. A blog will be the channel you tell the stories that help consumers understand the value that an API delivers, how other developers are integrating with it, ultimately leaving an SEO exhaust that will bring in new consumers. If comments are in place, a blog can also provide another channel for opening up conversation with API consumers and the public.
Without an understanding of the industry an API is operating in, an API will not effectively serve any business sector. By establishing and maintaining a relevant keyword list, you can monitor competitors, companies that compliment your platform, and establish an active understanding of the business sector you are trying to serve. Regular monitoring and analysis of the business landscape is necessary to tailor a meaningful API evangelism campaign.
When it comes to evangelism, support is one of the most critical elements. There is no better word of mouth for an API, than an existing consumer talking about how good the API is, and the support. Engage and support all API consumers. This will drive other vital parts of API evangelism, including creating positive stories for the blog, healthy conversations on social networks and potentially creating evangelists within a community.
I recommend a lot of online services and tools for API providers and consumers to put to use. But there is not any single platform that delivers as much value to the API space as Github. I would put AWS as close second, but Github provides a wealth of resources you can tap when both providing APIs or building applications around them. Github is a critical piece of any API strategy, allowing social relationships with developers that is centered around code samples, libraries or even documentation and resources for an API.
Twitter, Facebook, LinkedIn, Google+ and Github are essential to all API evangelism strategies. If an API does not have a presence on these platforms, it will miss out on a large segment of potential API consumers. Depending on the business sector an API is targeting, the preferred social network will vary. Providing an active, engaging social support presence when operating an API is vital to any API ecosystem.
Discovery and curation of bookmarks to relevant news and information via social bookmarking platforms is essential to an active API evangelism strategy. Using Reddit, Hacker News and StumbleUpon will provide discovery and access to a wealth of resources for understanding the API space, but also provide an excellent channel for broadcasting blog posts, news and other resources about API operations, keeping consumers informed, while also opening up other opportunities for discovery.
API providers, and API consumers are constantly building trust and establishing a long term relationship with each other. One key facet of this trust, and the foundation for the relationship is sharing a common road-map. API providers need to actively involve API consumers with where the API resources are going, so that consumers can prepare, adjust and even give feedback that may, or may not, influence the road-map. Nothing will piss off API consumers faster than keeping them in the dark about what is coming down the pipes, and surprising them with changes or breaks in their applications.
A healthy online presence is critical to any successful API strategy, but giving attention to a strong in-person presence at events is also a proven tactic of successful API providers. Evangelism involves a coordinated presence at relevant conferences, hackathons and local meetups. Events are necessary for building personal relationships with partners and API consumers that can be re-enforced online.
Measuring every aspect of an API operations is necessary to understand what is happening in any API operations. Reporting on every aspect of API operations is how you visualize and make sense of some often, very fast moving API activity. It is important to quantify API operations, and develop reports that are crafted to inform key stakeholders about an API initiative.
External facing activities will dominate any active API operations. However, an essential aspect of sustainable API programs is internal evangelism. Making sure co-workers across all departments are aware and intimate with API operations, while also informing management, leadership and budget decision makers is critical to keeping API doors open, healthy and active.
API and developer evangelism is an iterative cycle. Successful API operations will measure, assess and plan for the road-map in an ongoing fashion, often repeating on a weekly and monthly basis to keep cycles small, reducing the potential for friction in operations and minimizing failures when they happen.
A healthy API evangelism strategy will be something that is owned partially by all departments in a company. IT was a silo, APIs are about interoperability internally and externally.
Marketing to developers is no straightforward task, and with the growth in the number of APIs, platforms, tools and active evangelists and advocates, it is only going to get harder.
Developers just don’t want to be sold anything. We just want to do what we do, and just be left alone--until we need help and reach out. Then we need you to be there.
With API Evangelist I’m evangelizing the importance of APIs to a wider audience beyond developers, while also helping companies understand how they can market their services to developers.
Helping non-developers understand about APIs is getting easier each month, while helping API owners market to developers is getting harder.
Many companies are even opting to not use the term advocate or evangelist, as these names are beginning to have a negative impression with developers.
Developers are bombarded by one or many evangelists, everywhere they go, and many of these evangelists are more sales and marketing than developer support--giving everyone a bad name.
If you are looking to evangelize your API in the near future, deeply consider your approach. Your objective is not to sell developers on your API, but to help them be successful in what they are doing--something that may or may not involve your companies API.
Your only option for evangelism is to be as authentic as possible and truly solve the problems developers face, otherwise developers will look elsewhere--and with the increased competition, developers have a growing number of options when it comes to APIs and platforms to get the job done.
One very important aspect of API Evangelism is landscape analysis. When you launch an API, you need to have an intimate understanding of the landscape where you will be evangelizing your API and engaging with potential consumers.
I always start by establishing potential 10K foot target areas that I will focusing on in my research. While these may vary from industry to industry, my starting list is:
- Individuals - Who are the key individual influencers in your target landscape
- Competitors - Know your competitors, you can learn a lot from what they do right or they do wrong
- Platforms - There are an endless amount of platforms that may benefit your company, such as Drupal, Wordpress and Salesforce
- Media - Who are the relevant media and blogs you should be following and engaging with
- Partners - Existing partners who you should be in tune with on the landscape
After tackling these areas and identifying who the players are, you will identify other areas that are unique to your API evangelism efforts, so don't stress over whether you have the right areas in the first week. While researching these areas of my landscape I try to identify specific channels for getting plugged in with landscape targets:
- Website URL - What is the targets root URL for their website
- Blog URL - What is the blog for a target
- Blog RSS - Secondary to the blog, what is the RSS feed so I can programmatically monitor
- Twitter - What is a companies or individuals Twitter handle
- LinkedIn - Identify and sometimes connect with a target’s LinkedIn account
- Facebook - Identify and sometimes connect with a target’s Facebook account
- Github - Identify, follow and engage with a companies Github profile and appropriate repositories
After getting the primary channels for each target on my landscape identified, I will go deeper sometimes and actually identify key individuals associated with target companies, either the founders and / or key employees. I look for Twitter, LinkedIn, Facebook and Github for individuals as well, and sometimes even personal blogs when available.
While landscape analysis is an initial project in the first couple weeks of designing your API evangelism strategy, it will be ongoing iniative, in monitoring all target channels in real-time, but also identifying new target groups, companies and individuals or even specific channels not listed above like Tumblr or Google+ each week.
Each industry will be different when identifying the landscape for your API evangelism efforts, but this is a good first round blueprint and has worked well for me on multiple projects. Let me know if there are any landscape analysis and monitoring tricks you use.
Mobber's service is obviously in direct competition with Twitter's Promoted Trends, part of Twitter's suite of advertising products, which also includes promoted accounts and promoted Tweets.
Of course it's Twitter's platform, they can shut off anyone's access, and easily file it under a terms of service violation. But ultimately wouldn't it make more sense if Twitter opened it's advertising platform with APIs, and allowed developers to innovate, enabling Twitter to still make money, but providing a much wider reach and audience?
Mobber's story is just another casualty in Twitter recent efforts to take control of it's platform, leaving developers to wonder, who is next?
I just finished a four week roadshow that included three Startup Weekend EDU events -- one in Seattle, one in San Francisco and one in Washington DC -- as well as two versions of the Business of APIs conferences -- one in San Francisco and one in New York City.
It might not seem at first glance that these events had much in common. During the Startup Weekends, business people, teachers and developers rallied to build startups that focused on solving problems in education, while the Business of APIs conferences showcased businesses telling their stories about how opening up data and APIs have transformed them and made them more competitive within their respective industries.
Both events re-enforced for me the importance of both on-the-ground and online evangelism. Both are necessary for ensuring the success of open data and APIs.
At both series of events, I encountered many people who had never heard of Twilio or Amazon Web Services -- two API providers that are leaders in their industries (as well as were sponsors at the events). Both Twilio and Amazon Web Services provide essential cloud resources that can be used by any company and developer, but without the proper awareness and education, these resources go unused. Both companies are active in sponsoring start-up weekends, hackathons, codeathons, meetups and the like, but Twilio does much better at having "boots on the ground" at these events. This presence is one of the things that has made Twilio a developer favorite and, in turn, spawned thousands of apps and many start-ups. But clearly they still have work to do to get their name "out there," particularly at events outside of Silicon Valley.
But having someone on-the-ground isn't always enough. At the Startup Weekend EDU events, for example, there were several people present from the Department of Education and to their credit, they spent the entire time engaging and listening to business people, teachers and developers about what they needed. That was great to see, but at the same time, but there were no materials there about the amazing data and APIs provided by the Department of Education at data.ed.gov and no real encouragement of developers to take advantage of these things.
It seems as though we are missing the opportunity to help people become familiar with the various resources that the Department of Ed (along with its parent data.gov site) offers. As code-athons and other startup-building events continue to spread, it seems a shame to not take better advantage of these tools.
The tech companies do send out their developer advocates and evangelists to "get the word out." Facebook, Google, Twitter, Twilio and the like all have an army of these sorts of people to help others work with their data and their APIs.
Now that the government has opened its data, it seems as though the missing piece might be this evangelism element -- taking the open data on the road, from town to town, making the wealth of resources available at data.gov known and challenging some of our brightest minds to get involved to make our country a better place.
If you think there is a link I should have listed here feel free to tweet it at me, or submit as a Github issue. Even though I do this full time, I'm still a one person show, and I miss quite a bit, and depend on my network to help me know what is going on.