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 defining not just their APIs, but their schema, and other moving parts of their API operations.29 Aug 2018
I am always fascinated when I get push back from people about API management, the authentication, service composition, logging, analysis, and billing layer on the world of APIs. I seem to be find more people who are skeptical that it is even necessary anymore, and that it is a relic of the past. When I first started coming across the people making these claims earlier this year I was confused, but as I’ve pondered on the subject more, I’m convinced their position is more about the world of venture capital, and investment in APIs, that it is about APIs.
People who feel like you do not need to measure the value being exchanged at the API layer aren’t considering the technology or business of delivering APIs. They are simply focused on the investment cycles that are occurring, and see API management as something that has been done, it is baked into the cloud, and really isn’t central to API-driven businesses. They perceive that the age of API management as being over, it is something the cloud giants are doing now, thus it isn’t needed. I feel like this is a symptom of tech startup culture being so closely aligned with investment cycles, and the road map being about investment size and opportunity, and rarely the actual delivery of the thing that brings value to companies, organizations, institutions, and government agencies.
I feel this perception is primarily rooted in the influence of investors, but it is also based upon a limited understanding of API management, and seeing APIs being a about delivering public APIs, maybe with a complimenting a SaaS offering, and a free, pro, and enterprise tiers of access. When in reality API management is about measuring, quantifying, reporting upon, and in some cases billing for the value that is exchanged at the system integration, web, mobile, device, and network application levels. However, to think API operators shouldn’t be measuring, quantifying, reporting, and generating revenue from the digital bits being exchanged behind ALL applications, just demonstrates a narrow view of the landscape.
It took me a few months to be able to see the evolution of API management from 2006 to 2016 through the eyes of an investment minded individual. Once the last round of consolidation occurred, Apigee IPO’d, and API management became baked into Amazon, Google, and Azure, it fell of the radar for these folks. It’s just not a thing anymore. This is just one example of how investment influences the startup road map, as well as the type of thinking that goes on amongst investor influence, painting an entirely different picture of the landscape, than what I see going on. Helping me understand more about where this narrative originates, and why it gets picked up and perpetuated within certain circles.
To counter this view of the landscape, from 2006 to 2016 I saw a very different picture. I didn’t just see the evolution of Mashery, Apigee, and 3Scale as acquisition targets, and cloud consolidation. I also saw the awareness that API management brings to the average API provider. Providing visibility into the pipes behind the web, mobile, device, and network applications we are depending on to do business. I’m seeing municipal, state, and federal government agencies waking up to the value of the data, content, and algorithms they possess, and the potential for generating much needed revenue off commercial access to these resources. I’m working with large enterprise groups to manage their APIs using 3Scale, Apigee, Kong, Tyk, Mulesoft, Axway, and AWS API Gateway solutions.
Do not worry. Authenticating, measuring, logging, reporting, and billing against the value flowing through our API pipes isn’t going anywhere. Yes it is baked into the cloud. After a decade of evolution, it definitely isn’t the early days of investing in API startups. But, API management is still a cornerstone of the API life cycle. I’d say that API definitions, design, and deployment are beginning to take some of the spotlight, but authentication, service composition, logging, metrics, analysis, and billing will remain an essential ingredient when it comes to delivering APIs of any shape or size. If you study this layer of the API economy long enough, you will even see some emerging investment opportunities at the API management layer, but you have to be looking through the right lens, otherwise you might miss some important details.
404: Not Found
I have a lot of conversations with folks down in the trenches about API security, and what they are doing to be proactive when it comes to keeping their API infrastructure secure. The will and the desire amongst folks I talk to regarding API security is present. They want to do what it takes to truly understand what is needed to keep their APIs secure, but many have their hands tied because lack of resources to actually do what is needed. Every API team I know is short-handed, and doing the best they can with what they have available to them. A lack of investment in API security isn’t always intentional, it ends up just begin a reality of the priorities on the ground within the organizations they work in.
While I’m sure leaders within these companies are concerned about breaches within their API infrastructure, the urgency to invest in this area isn’t always a priority. Despite an increase in high profile, often API-induced breaches, IT and API groups are still not given the amount of resources they need to do something about potential security incidents. Other than the stress and bad press of a breach, there really are no consequences in the United States. We have seen this play out over and over, and when high profile breaches like Equifax go unpunished, other corporate leaders fully understand that there will no consequences, so why invest in preventative measures–we will just respond to it “if” it happens.
This is why GDPR, and other similar legislation will become important to the API security industry. Without real civil or criminal penalties involved with breaches, and even heavier penalties for poorly handled breaches, companies just aren’t going to care. Data is just a replaceable commodity, and a company can recover from the hit to their brand when a breach does occur. Making the investment in proactive API security training, staffing, services, and processes an unnecessary thing. Reflecting how health care is handled in this country, with 95% of the investment in treating things after they happen, and about 5% investment in preventative care. Hoping all along you don’t get sick, or have a breach.
I can talk until I blue in the face to business leaders about API security, and make them aware of healthy practices, but if there isn’t an incentive to invest in API security, it will never happen. At this point I feel that API security is more a reflection of a wider systemic illness around how we view data, and that country and industry level policy is where change needs to occur. I will keep showcasing specific building blocks of an API security strategy, as well as showcase services and tools to help you implement your strategy, but I feel like the most meaningful change will have to occur at the policy level. Otherwise business leaders will never prioritize API security, leaving all of OUR data vulnerable to exploitation–it is just a cost of doing business at this point.
I get a lot of emails from companies asking me to look at their APIs. Too many for a one person operation like me to consider. I have to be picky about the APIs I’m taking a look at, and over time I’ve developed a set of criteria for determining how much energy I will invest in an API. Usually within about 2-3 minutes I can tell if it is an API I will be diving in deeper, or I will just be walking away and moving on with my work.
The first thing that turns me off of an API is that it just isn’t interesting. I’ll land on the page and I can tell what it does, but it just doesn’t interest me. It doesn’t offer any value, or it is in a category that I’m just not eager to be thinking about and showcasing in my work. If an API doesn’t deliver value, and stand out as being interesting beyond the hundreds of other APIs I see each week, I’m just not going to stop and take notice. Sorry, it might be to others–don’t just take my opinion.
The next thing that keeps me from going deeper is I can’t tell what an API does. I’m always amazed at how much head scratching, clicking and reading I will do before I ever figure out what an API does. I’m pretty hard headed, so sometimes its me, but other times I’m just stuck at figuring out what is going on under the hood. Usually after about 3-5 minutes of struggling to understand what is happening, I will just walk away. It is unlikely that other folks will be investing more time than that, and the API will not last long in my experience.
After that, the biggest crime I see companies and organizations make is that they just do not invest enough into a dedicated portal, and the other supporting resources for their API. If someone sends me a link to their API and it is in the help or knowledge base section of their website, I know that they don’t really care about it, and won’t be investing much more into it. APIs shouldn’t be a side project for companies in 2017, they should be front and center, in their own dedicated portal, with a prominent link off the website navigation.
I try to always respond to emails I get from folks letting them know their API efforts fall short of what I’m expecting to see. I feel bad raining on their parade, but the bar is pretty high in 2017. Your API needs to stand out, deliver value, and be something you are investing in. Maybe my response will light the fire under your API operations, and at least get you reading my blog some more, and learning about what other API providers are doing. Then you can take some of what you’ve learned back to your organization and get to work building a first class API operation.
I’ve been diving into the fundamentals of API management as part of several projects I am working on. I am setting up API management for a single API project, as well as thinking through API management practices across many API implementations in a single industry. I also just had lunch with a friend at an API startup I work with who is looking to invest in me doing some further research and storytelling when it comes to API management. All of this is providing me with a great opportunity to step back and think about API management from the small detailed moving parts, all the way up to the industry, regulatory, and macro levels of managing digital resources online.
API management is the oldest aspect of my research, and one I still think is one of the most critical aspects of doing APIs in my opinion. While there are many features modern API management brings to the table, the core of it is all about allowing consumers to sign up to access some data, content, media, or algorithm. Each consumer receives a set of keys that will identify and allow for their access to be measured, which then allows the owners or stewards of digital resources to develop awareness around who is accessing a resource, and what they are doing with it. Some call it security, others analytics, but I see it about developing an awareness and asserting control over our digital resources.
If you are focused on monetization, API management is about generating revenue. If you are worried about who has access to your digital assets, API management is about security. If you are doing API management right you realize it is about being aware of the digital resources you have, working to make sure they are well defined, and are tuned into your API management dashboard to understand how they are being used (or not used). I feel like this has been one of the shortcomings of an VC led world of API management, is that it became heavily focused on restricting and controlling access, and fixated on generating revenue, leaving a significant amount of opportunity on the table for making sense of the digital resources we all depend on, and maximizing their access, usage, and yes, revenue.
I see more investment in APIs when it comes to startups getting access to resources. I also see heavy investment when it comes to APIs generating new data points (home, auto, wearables, sensors, etc.) However, when it comes to understanding and quantifying the data, content, and algorithms already in use, there just isn’t much investment. Not there isn’t value there. There just isn’t enough value there to attract VC level interest. I feel like the tech sector wants APIs for all the wrong reasons. The reasons that benefit them. The pervasiveness nature of this way of thinking has stagnated companies, organizations, institutions, and government agencies from establishing control over their vital digital resources, developing awareness, and establishing control, using API management.
I was listening to Mark Zuckerberg talk about how security investments will affect the platforms profitability on the Facebook earnings call this last week. This line of thinking sounds pretty consistent with what I’m hearing from other folks when it comes to why they haven’t been investing more into their API security. My challenge for this line of thought is about shutting down proactive security investments, and does not speak of responsive security investments–meaning after you’ve had a breach, or when there is other security investment. From a leadership perspective this view of security just doesn’t do it for me, and I’d push back, and require it consider what profitability will look like if we do not invest properly in security.
Viewing security in this way is common. It is also a short-sighted view of security, in the name of profits today, over health of a platform down the road. It demonstrates that leadership is more focused on profits, than whatever the platform focus actually doing. I would add that I think this line of thinking reflects a perspective of leadership that is out of sync with the technical details of operating a platform, and the current threat landscape. I get that a company has to be profitable, and that it is the job of the CEO is to represent the investors, but after Equifax, and the many other breaches, as well as what I’m seeing on the ground at companies I’m talking to, it is pretty clear that things are out of whack when it comes to overall security investment.
I work with a lot of folks who want to invest in API security more, but they just don’t have the resources. I’ve been in leadership roles where I’ve had my hands tied when it came to decisions around infrastructure to deliver on PCI, and other compliance, as well as being able to hire security focused talent. This type of thought regarding security practices tends to make investors and other leadership happy, but is corrosive to the actual health of operations. This stuff shouldn’t be about profits or security, it should be about doing what is needed for security, then making assessments regarding how that impacts the bottom line. Security shouldn’t be polarized like this, and it should reflect proactive, as well as responsive costs, as well as practices.
This isn’t a technology of API security story, this is a politics of API security story. This type of response and tone from leadership is something that the majority of my readers will experience when trying to grow their API security efforts. Investment in API security will continue to be a challenge for most companies, organizations, institutions, and government agencies in coming years. As I do with other stops along the API life cycle, I’m going to spend more time developing stories to push back on leadership telling stories about investments in security. My goal is to have a toolbox of examples to help educate the people making security investment decisions that investment in API security now, will pay off later, and cost a lot less than investment in API security after the fact.
Amazon Web Services recently updated their billing for EC2 instances to be by the second, which I really like, because I’ll fire up an instance and run for minutes, then shut things down. I’m just looking to process patent downloads, or other intensive workload projects. Beyond just EC2, the rest of Amazon’s platform is still very usage based. Meaning, you get charged for whatever you use, with unit pricing for each resource designed to compliment how it gets put to use. You get charged for the hard costs of compute, storage, and bandwidth, but you also see per message, job, entry, and other types of billing depending on the type of resource being delivered via API.
With this model for doing APIs, I’m wondering why so many API providers still have access plans and tiers. I’ve vented several times that I think service tiers are a legacy of a SaaS way of thinking and does not scale for API consumers. Maybe back when we used a handful of APIs, but the number of APIs I’m using is pushing 50 these days, and I can’t alway justify a monthly subscription to get what I need. I’m looking to just get access to valuable API resources, and get billed for whatever I use. If I don’t use anything for 6 months, I don’t get billed for anything. Also, I want to be able to run large jobs which consume intense amounts of resources without hitting tier and other limits–just charge me for what I use. If I have a $1,000.00 to spend today, let me spend it. Don’t make me jump through hoops.
I know the answer to my question regarding why so many API startups do this. It is because the resources being provided via the API isn’t the product, us API consumers are. They are looking to ensure a certain level of headcount, monthly, and annual subscribers, so that they can sell us to their investors, and ultimately whoever purchases us like cattle in the end. I’m sure there are other reasons for having pricing tiers, but this is still the primary reason we see SaaS based pricing continue to be so pervasive in an API driven world. For me, if an API provider has tiered pricing, I’ll almost always go look elsewhere. I just can’t manage 40 or 50 subscriptions, and if the number of APIs keep growing, I can’t handle 100-200 subscriptions. I just need to pay for the resources my business needs, and nothing more. I sure don’t have time to be a product in your startup cattle auction.
Pay as you go, usage based pricing is one way the cloud giants will suffocate out the small startups in the future. While startups are trying to court investors, and their acquirers, the cloud giants will just offer a competing service, drop the price to run competitors off, then once the coast is clear, raise prices back up to an profitable state. To compete, more API providers will have to go with a utility based pricing strategy, while also offering wholesale versions of their APIs in the marketplaces for AWS, Azure, and Google. I can’t help think that things might have been different if the scales didn’t tip so hard towards all of us API consumers being the product, and API providers focused more on running businesses, and catering to our real world business needs. Oh well, we got the world we have, I’ll just keep plowing forward.
People love to point out that APIs are unreliable. You can’t depend on them. They go away at any point, and they just aren’t something you want to be building your business on top of. When in reality APIs aren’t reliable it is the business, people, and investment behind them. The reality of the startup game is that us API consumers aren’t actually the customer, we are just numbers in a larger game where startup founders and their investors are looking for enterprise customers to purchase their startup getting the desired exit. The API is just about attracting consumers, who will do the legwork to bring in users, adding to the value of a company.
As the startup funding landscape continues to dry up, shift, and evolve towards more riskier and volatile versions of investment like ICOs, things are only going to get worse. Of course, few conversation will place the blame on the people and companies behind, but APIs will continue to be the scapegoat for the instability. It works just like the robots coming for your jobs. You never hear that rich people who own companies, that are making decisions to replace workers with robots are coming for your jobs. Its the robots. Technology in many forms makes for a great blame shield, absorbing the responsibility for the volatility, instability, and scams that are going on across the landscape.
In reality, nothing much changes for us API consumers. You need to get to know your API providers, well as the company and people behind them. Study their approach to operating their API. Do they communicate? Do they have proper support? Do they communicate their uptime status? What type of funding is propping them up, and the shape of their business model use. Make sure you always have a plan B if you can, and do not trust that ANY API will be around forever. If possible, come up with failover plans, and run drills with your team regarding what will happen when APIs fail, become unreliable, or go away entirely. Ultimately it is up to you to determine the impact unreliable APIs will have on your APIs. We can blame API providers, startups, and VCs as much as we want, but it is entirely up to us to help stabilize the API space for our users.
Investment, fundraising, and chasing exits will be the #1 area of instability for the API space. After that it will be the network, ranging from network neutrality going away to lack of investment in capacity and security. While the growth in the number of companies, organizations, institutions, and government agencies doing APIs will keep things on forward trajectory, the reputation of APIs will continue to take a hit when it comes to the stories people tell about who is to blame. APIs are the frontline for almost everything occurring online these days, and this will make it the first place everyone will be pointing the finger. It is up to us in the API community to keep telling stories putting the blame where it is deserved. If we are not telling stories, the other side will, and they’ll be firing up the pundits, continuing to let irresponsible API startups get away with their bullshit games.
Note: If my writing is a little dark this week, here is a little explainer–don’t worry, things will back to normal at API Evangelist soon.
I’m really honored that some of my partners are kind enough to offer me a piece of the action in their companies, in exchange for what I do. I really am. However, going forward I’m going to have to decline any stock options in exchange for work, or advising, because it really doesn’t pencil out for me. I know it is the currency you are working with, getting investment in exchange for options, and trying to get knowledge, talent, and other forms of investment in exchange as well. I trust it will work out in your favor, but from my vantage point, there really is no upside in the game.
I regularly receive accusations of having and agenda because of real or perceived interest in companies, so with this hit on my brand, and the lack of return from the historic stock options I’ve had historically, it just doesn’t work out. My last advisor options netted me $319, for about 60 hours of work on, and travel costs out of my own pocket. I’m sure if I had more capital investment, and a bigger piece of the action, I’d fare better, but for the stake I get thrown–it just doesn’t do it for me. Plus, I have a manila folder in the filing cabinet of more significant shares that aren’t worth the paper they are printed on, so stock options really doesn’t float my boat in the first place.
Please don’t let this hurt your feelings. I know you are heavily invested in the value of your options, but I’m just not there. I’m happy to find other arrangements to make things happen, but with the way that stock options get wielded against me, and used to potentially discredit what I’m doing, it just isn’t worth anymore. As it stands today I only have stake in a single company–Skylight Digital (5%). I have NO stake in any API related company, and I am going to keep it that way. I’m not 100% against an equity stake, but the risk of low stake investments, and the high risk of damage to my brand leaves me extremely critical about any conversation in this area.
It is another fascinating area of the startup game in my view, where people like punching down, instead of up when it comes to questioning the ethics and credibility folks in the API space. People be all questioning my ethics, but afraid to ever go after startups, or investors, because it might hurt their chances to be invited into the club some day! It’s a crazy financing reality in the API space, where up is down, and down is up, and I’m just beating that API Evangelist drum. #onward
Note: If my writing is a little dark this week, here is a little explainer–don’t worry, things will back to normal at API Evangelist soon.
I had a friend ask me for my thoughts on bots. It is a space I tend to rant about frequently, but isn’t an area I’m moving forward any meaningful research in, but it does seem to keep coming up and refuses to ever go way. I think bots are a great example of yet another thing that us technologists get all worked up about and think is the future, but in reality, while there will only be a handful of viable use cases, and bots will cause more harm, than they ever will do any good, or fully enjoy a satisfactory mainstream adoption.
First, bots aren’t new. Second, bots are just automation. Sure, there will be some useful automation implementations, but more often than not, bots will wreak havoc and cause unnecessary noise. Conveniently though, no matter what happens, there will be money to be made deploying and defending against each wave of bot investment. Making bots is pretty representative of how technology is approached in today’s online environment. Lot’s of tech. Lot’s of investment. Regular waves. Not a lot of good sense.
Top Bot Platforms Ok, where can you deploy and find bots today? These are the dominant platforms where I am seeing bots emerge:
- Twitter - Building bots on the public social media platform using their API.
- Facebook - Building Facebook messenger bots to unleash on the Facebook Graph.
- Slack - Building more business and productivity focused bots on Slack.
There are other platforms like Telegram, and folks developing interesting Github bots, but these three platforms dominate the conversation when it comes to bots in 2017. Each platform brings it’s own tone when it comes to what bots are capable of doing, and who is developing the bots. Another important thing to note across these platforms is that Slack is really the only one working to own the bot conversation on their platform, while on Facebook and Twitter allow the developer community to own the conversation about exactly what are bots.
Conversational Interfaces When it comes to bots, and automation, I’m always left thinking more broadly about other conversational interfaces and Siri, or more specifically Amazon Alexa. The Amazon Alexa platform operates on a similar level to Slack when it comes to providing developers with a framework, and tooling to define and deliver conversational interfaces. Voice just happens to be the interface for Amazon, where the chat and messaging window is the interface for Slack, as well as Twitter and Facebook. Alexa is a bot, consuming API resources alongside the other popular definitions of what is a bot on messaging and social channels–expanding the surface area for how bots are deployed and engaged with in 2017.
Bots And APIs To me, bots are just another client application for APIs. In early days APIs were about syndicating content on the web, then they were used to deliver resources to mobile applications, and now they are delivering content, data, and increasingly algorithms to devices, conversational interfaces, signage, automobiles, home appliances, and on and on. When any user asks a bot a question, the bot is the making one or many API calls to get the sports statistic, news and weather report, or maybe the purchase of a product. There will be many useful scenarios in which APIs will be able to deliver critical resources to conversational interfaces, but like many other client implementations, there will be many, many bad examples along the way.
Algorithmic Shift In 2017, the API space is shifting gears from primarily data and content based APIs, to a more algorithmic focus. Artificial intelligence, machine learning, deep learning, cognitive, and other algorithmically fueled interfaces are emerging, wrapped in APIs, intent on delivering “smart” resources to the web, mobile, and conversational interfaces. We will continue to see an overwhelming amount of discussion at the intersection of bots, API, and AI in coming years, with very little actual results delivered–regardless, there will be lots of money to be made by a few, along the way. Algorithms will play a central role in ensuring the “intelligence” behind bots stay a black box, and sufficiently pass as at least magic, if not entirely passed off as comparable to human intelligence.
Where Will The Bot Money Be? When it comes to making money with bots, there will only be a couple value creation centers. First, the platforms where bots operate will do well (most of them)–I am not sure they all will generate revenue directly from bots, but they will ensure bots are driving value that is in alignment platform revenue goals. Next, defensive bot solutions will generate sufficient amounts of revenue identifying and protecting businesses, institutions, and government agencies from the bot threat. Beyond that, venture capital folks will also do well investing in both the bot disruption, and bot defensive layers of the conversation–although VCs who aren’t directly involved with bot investment, will continue to be duped by fake users, customers, and other bot generated valuations. Leaving bot blemishes on their portfolios.
Who Will Lose With Bots? Ultimately it is the rest of us who will come out with on the losing side of these “conversations”. Our already very noisy worlds will get even noisier, with more bot chatter in the channels we currently depend on daily. The number of humans we engage with on a daily basis will decrease, and the number of frustrating “conversation” we find ourselves stuck in will increase. Everything fake will continue inflate, and find new ways to morph, duping many of us in new and exciting ways. Markets will be noisy, emotional, and always artificially inflated. Elections will continue be just an an outright bot assault on voters, leaving us exhausted, numb, and pretty moldable by those who have the biggest bot arsenals.
Some Final Thoughts On Bots I am continuing to see interesting bots emerge on Twitter, Facebook, Slack, and other channels I depend on like Github. I have no doubts that bots and conversational solutions will continue to grow, evolve, and result in a viable ecosystem of users, service providers, and investors. However, I predict it will be very difficult for bots to ever reach an acceptable mainstream status. As we’ve seen in every important conversation we are having online today, some of most badly behaved amongst us always seem to dominate any online conversation. Why is this? Bots. We will see this play out in almost every business sector.
I was talking to a VC about one of my favorite API upstarts the other day, and one of the closing questions I received was if the API upstart had a secret sauce that made their position defensible. To which I responded, no…but they are API first, and API definition-driven in everything they do, so they will ultimately move faster than any competitor can.
Agility is one of the classic things you hear people tell companies regarding why they should be doing APIs. The benefit is definitely overused and overstated in situations it shouldn’t be, but when APIs are fully embraced, and done properly, the agility is real. I’ve seen companies be able to shift, pivot, and add new features in a fraction of the time of their competitors, allowing them to in new ways that nobody had intended just months before–APIs allow for the type of shape shifting you need to remain competitive in today’s environment.
APIs do not automagically mean a company, institution, organization, or agency will be agile by default. Organizationally, and culturally the entity behind an API needs to be in sync with the API frontline, or agility will never be fully realized. However, when you can dial all this in I’ve seen something that is more potent than any secret sauce or proprietary approach, allowing you to move more confidently and flexibly. I don’t think API agility is a competitive advantage that all companies or investors fully grasp, but once they see in action, I think they’ll realize APIs are more effective than locking something up and keeping it secret.
It is a hustle to do API Evangelist. I've been lucky to have the support of 3Scale since 2013, without them API Evangelist would not have survived. I'm also thankful for the community stepping up last year to keep the site up and running, keeping it community focused thing, and not just yet another vendor mouthpiece. I make my money providing four ad slots on the site, by selling guides and white papers, and by consulting and creating content for others. It is a hustle that I enjoy much more than having a regular job, even though it is often more precarious, and unpredictable regarding what the future might hold.
Taking money from companies always creates a paradox for me. People read my stories because they tend to be vendor neutral and focus on ideas, and usable API-centric concepts. While I do write about specific companies, products, services, and tooling, I primarily try to talk about the solutions they provide, the ideas and stories behind them, steering clear of just being a cheerleader for specific vendor solutions. It's hard, and something I'm not always successful at, but I have primarily defined my brand by sticking to this theory.
This approach is at odds with what most people want to give me money for. 3Scale has long supported me and invested in me being me, doing what I do--which is rare. Most companies just want me to write about them, even if they understand the API Evangelist brand. They are giving me money, and in exchange, I should write about them, and their products and services. They often have no regard to the fact that this will hurt my brand, and run my readers off, falling short of actually achieving what they are wanting to achieve. I get the desire to advertise and market your warez, but the ability for companies to be their own worst enemy in this process is always fascinating to me.
I get regular waves of folks who want to give me money. I'm talking with and fending off a couple at the moment. So I wanted to think through this paradox (again), and talk about it out loud. It just doesn't make sense for me to take money from a company to write blog posts, white papers, and guides about their products and services. However, I feel like I can take money from companies to write blog posts, white papers, and guides about an industry or topic related to the problems they provide solutions for, or possesses a significant audience that might be interested in their products and services. I consider this underwriting and sponsorship of my API Evangelist research, where they receive branding, references, and other exposure opportunities along the way.
Ideally, all branding, reference, and exposure elements are measurable through the tracking of impressions and links. What was the reach? What is the scope of exposure? It is difficult to sustain any relationship without measuring success and both parties are unable to articulate and justify the financial underwriting and support. In some cases, I get paid a finder's fee for referrals, but this can be very difficult to track on and validate--something that requires a company to be pretty ethical, and truly invested in partnerships with smaller brands like me. I prefer to rely on this, as opposed to any sort of affiliate or reseller style tracking systems. I like companies that ask their customers, "how did you learn about us?", as they tend to actually care about their employees, partners, other stakeholders at a higher level.
Sometimes I take an advisor, or even technology investor role in startups, taking on a larger stake in outcomes, but these are something that is very rare. I have a manila file folder filled with stock options, and stakes I have in companies that never reached an exit, or when they did I was written out of things--when I do get a check from startup founders, I'm always floored. This does happen, but is truly a rare occurrence. I wish there were more decoupled, plug and play opportunities to invest in startups as an advisor, researcher, analyst, and storyteller, but alas the system isn't really set up for this type of thinking--people prefer the big money plays, over smaller, more meaningful contributions--it's about the money man.
Anyways, every time I visit this conversation in my head I come back to the same place. I'm happy to take money from companies to generate short form and long form content about an industry or topic. If there are finder fees for referrals, great! I leave it up to you to track on and come back to me with the details, and any specific event--while I will stay focused on what I do best, the thing you are investing in me to do. I'm mildly interested in opportunities to become more invested in your companies overall success, honestly, I just don't trust that the system will deliver in this area, and is more often just looking to extract value from me. I have seen too much in my 30-year career. However, I always welcome folks who want to prove me wrong! ;-)
In the end, my mission stays the same. I'm interested in studying where the API space has been, where it is at, and where it might be going. Then, I am interested in telling stories from what I learn in this process. If you want to invest in any of this, let me know. I could use your help.
It made me happy to read the Rise of Non “VC compatible” SaaS Companies, and see that there are more sensible discussions going on around how to develop SaaS business, something that I hope spreads into the specifically API as a product startups and API service providers. I know that many of my readers think I'm anti-VC--I am not. Or may I'm anti-startup--I am not. I'm anti-VC and anti-startup ideology becoming the dominant religion, pushing out a lot of really good people and ideas who can't play that game.
When it comes to Silicon Valley, if you push back, you get excluded from the club, and there are waves of people who step up to tell you "not all startups are bad" or "not all VCs are bad"--I wish I could help you understand how this response makes you look. Of course, they aren't all bad, but there are bad ones, and there is a lot of rhetoric that this is the ONLY way you can build technology when it isn't. There are plenty of ways you can develop technology, and build a business without the VC approach, or the cult of the startup.
There are more instructions you should follow in the rise of the non-VC compatible SaaS companies story, but the author outlines four types of SaaS companies, which I think applies nicely to APIi companies, as many of them will be SaaS providers:
- Funded SaaS: companies which finance their business with VCs a.k.a equity against money. From early stage startups with no revenue to companies going public with hundreds of millions of dollars of ARR, the range is extremely wide.
- Bootstrapped “scaling” SaaS companies: SaaS companies which manage to pass the $10M ARR threshold without VC money. Ex: Mailchimp or Atlassian (which raise VC money but at a very late stage) have reached the hundreds of millions of dollars of ARR without VC money. These “unicorns among unicorns” are very rare.
- Bootstrapped SaaS companies: bootstrapped companies which manage to reach the $300k — $10M ARR range without VC money.
- Bootstrapped Micro SaaS: “1 to 3” people companies which operate in the $1k — $300k ARR range, without VC money.
There are some ideas that should go VC, but there are even more that should not. I want to see more talk like this about the funding realities of an API startups. A sensible discussion about what the goals are, how fast a company should grow, and whether the company is building a business to develop software solutions that we sell to customers, or a business to sell some large enterprise--hell, maybe even go IPO. These are all viable options for your business, I'm just looking for more discussion about the priorities. One more thing, you should be having this discussion out in the open with the customers you are supposedly selling your products and services to--this is the important part, not just the having of the discussion.
I'm not trying to get in the way of you getting super filthy rich. I'm just trying to strike a balance between you building a company, and the stability and availability of your APIs, and API tools and services, in an industry I depend on to make my living. You see, APIs have gotten a bad wrap for not being stable, and going away at any time. This isn't an API thing, this is a VC funded startup thing. When you are telling your companies that you are building a business, with products and services to purchase, and then everyone bakes your solutions into their solutions, and you go away--that sucks. If you tell people the truth from the beginning and are honest and communicative about what your plans are, people can build and plan accordingly--the problem isn't APIs going away, it is startup founders not caring.
I am just trying to strike a balance between your business aspirations, and those of the people I help convince to use your APIs. Many of them aren't trying to get rich. They are just trying to build a business, and get their work done with your service, tool, and API. Let's start having more honest and open conversation about the variety of business models available to use when building API startups, and remember that not everything is a VC-worthy idea, sometimes you are just a viable feature for regular business owners like me.
I talk to venture capital (VC) folks on a regular basis, answering questions about specific API-centric companies, all the way to general trends regarding where technology is headed. This week I was talking with a firm about the viability of one of the API companies I work with regularly, and the topic of startup dependability came up, as we were talking about the challenges this particular startup is facing.
While I am using this particular startup in my business operations I expressed concern about the viability and stability of the startup in the long run. This concern has less to do with the startup, as I fully trust the team, and the technology they develop, it is more about the nature of how investment works, as well as the looming threats for the 1000lb pound gorillas in the space. I just do not trust that ANY startup will be around in coming months, and I craft my API integrations accordingly--always with a plan b, and hopefully a plan c waiting in the shadows.
This isn't just me. I've had similar conversations with companies of all shapes and sizes, university technology groups, as well as government agencies. After each wave of startups failing or achieving their exits, us end-users who are often in charge of purchasing decisions are suffering from whiplash, and our necks hurt. Every time there is a new tool on the table, we are asking ourselves whether or not it is worth it this time. Should we be investing in yet another software as a service that will likely go away in 12 to 24 months? The burden on us has been too high, and we are left feeling like the startups and their investors really do not give a shit about us--they have their own business model that they are moving forward with, where we are just a number.
There are no guarantees in business, but startups and VCs aren't doing enough to address the dependability of their portfolio companies. At some point, it will catch up with them, if it already isn't. As the API Evangelist, I am already toning down my excitement over new startups because I really do not want to be responsible for helping convince people to adopt a new tool, and then be held accountable when the startup goes away. Each week I have an inbox full of startups asking me to write about them, and most of them are unaware of how much my neck hurts, they are narrowly focused on their vision, with little concern for the rest of us, as long as they get their payout.
I have done a lot of reading in the last week, catching up on my monitoring of the API space. I have read a couple of posts about the reliability of APIs, and the overall viability of building applications, and businesses based upon them. A couple of the posts were focusing on the shuttering of ThinkUp, but a couple others were just part of the regular flow of these stories that question whether we can depend on APIs or not--nothing new, as this is a regular staple of bloggers and the wider tech blogosphere.
My official stance on this line of thinking is that I would not want to be building a business, and application that depends on leading API platforms like Twitter, Facebook, Instagram, and others, but I will happily build a business, applications, and system integration on APIs. You see, this isn't an API issue, it is a business and vendor viability issue. As with other sectors, there are badly behaved business, and there are well-behaved businesses--I try to choose to do business with the well-behaved one's (can't always achieve this, but I try).
I find the ongoing desire of the startup culture to point out how unreliable APIs are, while simultaneously supporting the overall business tone set by venture capital investment, often delusionally blind levels of support, is just not reconcilable. I'm not saying all VC investment is bad, so don't even take this down that road. I am saying that the quest for VC investment, and the shift in priorities once VC investment is acquired, then further shift with each additional round, and the final exit is setting a tone that is completely at odds with API reliability.
The problem really begins when APIs become the front-end for this blame. If I depend on vendors for my brick and mortar store, and the delivery trucks don't reliably bring my products, I don't talk about how you can't depend on trucks--I find new vendors. Of course, I can't find new vendors if they can't be replaced like Twitter and Facebook, but this is a whole other conversation, although it is also one that is a symptom of the tone being set by the VC currents (this is a business conversation). Blaming APIs instead of raising questions about the business ethics bar being set by venture capital shows the blinding power of greed, as the tech community refuses to blame VC $$, and shifts this to being about the viability of APIs, because I will get my VC $$ some day too bro!
I am not saying APIs are always good. I'm just saying they aren't bad. Hell, they aren't neutral. They are a simply a reflection of the business behind them, as well as being a reflection of the industry they operate in. Stop blaming them for businesses not giving a shit about developers, and the end-users. Maybe we could start changing the tone by admitting the #1 priority is always set by VC $$, and not by our API community, or even our end-users and customers, and all this shit is out of whack.
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.