Thursday, December 10, 2015

Machine Learning Will Lead When It Comes To Algorithmic Rent-Seeking

I've long been searching for a term to describe a concept that I see across the API space, where API providers, API consumers, and API service providers take more from the space, than they give back. This concept shows up across the API space in many forms, preying upon the open nature of the open nature of the API sector, and looking to extract value, and generate revenue on the backs of the hard work of others. 

After listening to the audio book version of the Price of Inequality by Joseph E. Stiglitz on a recent drive, I re-learned the term rent-seeking. A phrase I had heard before, but had not fully grasped its potentially wide meaning, when applied to financial products, natural, and other types of common resources--Google gives me the following definition:

Rent-Seeking When a company, organization or individual uses their resources to obtain an economic gain from others without reciprocating any benefits back to society through wealth creation.

Rent-seeking is common practice within the API layer of the Internet. When you consider the concept, and apply to the unlimited number of digital resources that are being exposed via APIs, you begin to see unlimited possibilities for rent-seeking, when transparency is not present. Now that I have the the seed planted in my head, and a phrase to apply, I will be exploring this concept more, but I couldn't help but think about one of the biggest offenders I'm seeing unfold across the space--machine learning.

Don't get me wrong. There will be a lot of machine learning solutions that will help move our digital world forward, but there are also lots of smoke & mirror machine learning and big data solutions, which will purely be seeking resources to mine. As an API provider, it can be easy to focus on the individual API consumers who are bad actors, when in reality you should be thinking much bigger, and the potential partners or service providers, who can consume large amounts, or even all of your resources.

This dark side of machine learning that I am focusing on will include the artificial intelligence, machine learning, big data, and analytics providers who will be selling you magical solutions and lofty promises, which will require the ingestion your valuable data, content, and algorithmic resources, before they can return said magic to you. Some of these solutions will offer more value than they consume, but many will not. If you are the steward of a valuable corpus of data, content, and have crafted valuable algorithms, many large companies will be approaching you in coming months and years, interested in helping you generate insights from these valuable resources.

Machine learning isn't bad. I just want to help you be aware that there are providers who just want to mine your resources, looking to add value to their own data, content, and algorithms, or possibly even just passing on, and selling it directly to other providers. Machine learning will be big business, and something that will dramatically incentivize rent-seeking behavior hidden behind an algorithm. I'll be telling stories of other rent-seeking behavior that I see in the API space, but at this point I feel like machine learning will lead when it comes to algorithmic rent-seeking in the API economy.


Friday, December 4, 2015

Not Every Band Needs To Sign With A Major Record Label Or Become An Orchestra

I used to work  in the music industry back in the 90s, and sometimes the tech sector reminds me of this time hustling in the music space. There are definitely a lot of things that are different, but the business of the tech space, often reminds me of some of the business currents that exist in the music industry. 

When you understand the lay of the land in the music industry, there are three distinct spheres of operating:

  • Independent - Small, successful bands who build a solid audience, and are able to make a living.
  • Label (Failure) - Bands that feel the need to be the next Led Zeppelin, and sell their souls.
  • Label (Success) - The small portion of bands who actually find large scale success, and get all the attention.

Most of the work I did in the music promotion space, existed within the world of independent or label (failure), with only one semi successful band, that had a brief flash of success, and I'd still actually put them in the label (failure) bucket, now that I think about it. There is a lot of money to be made as a promotion company selling services to bands who think they are going to make it big--they tend to sell everything, beg, borrow and steal to pay you. (sounds familiar)

There are some independent bands understand that they can actually make a decent living, making music through a mix of selling music, merchandise, and touring. Most other bands think they need to sign with a major label, when in reality the labels are just gambling and playing the numbers on the bands they sign. Only a small percentage of any record labels catalog will make them big money, the rest--marbles on the roulette table. Smart bands know they can do well, by playing good music, and running the business side well, where the not so smart bands always have to be famous, with only a small fraction ever making it--the rest burnout and fade away.

In the end, not every band needs to sign with a major record label, and not all bands needs to aspire to be an orchestra. This reminds me of tech startups, in that not all startups need to scale and sign with a VC, and definitely do not need to scale and become the next enterprise organization.


Thursday, December 3, 2015

If I Cannot Scale It On My Own Or Use A Service Provider I Do Not Scale It

I have had numerous startup ideas, half to full baked over my 25 year career, with just two I consider to be a success. All of them taught me massive lessons about myself, business, and building relationships with other people. All of this experience has gone into my invention of the API Evangelist persona, and there some hard learned lessons that dictate how I grow and scale what I do.

I do not scale anything I cannot scale by developing a new API, or putting a software as a service provider to use (which I can afford). The concept of hiring something does come into the picture from time to time, but always quickly fades. I feel this provides me with some very healthy constraints, that pushes me to really think through what scale is to API Evangelist. 

I have a huge laundry list of things I would like to do, but because it has to wait until I have the time, and energy to do, much of it never gets done, and that is a good thing. If it is critical, I will do it. If I feel it will help the API community at this point in time, I will do. If I can convince someone else to do, I will. ;-) Sometimes I just wait until someone else does it, and purchase their service. 

I am not saying this is an approach all companies should follow, I'm just sharing what approach works for me. My growth in site traffic, blog posts, industry guides, and revenue, has all happened slowly and steadily over time, in sync with the amount of work I do, and how much I am able to scale my own operations. This post is just a reminder for myself, to not get frustrated with my massive todo list, and scaling of API Evangelist has occurred, and it will never come as fast as I would like. 


Tuesday, December 1, 2015

All My Code Snippets Now Live As APIs Which Makes Them Way More Discoverable

Historically, I have a "working" Amazon EC2 micro instance, that is my playground for writing code. This is where I begin all my coding adventures, and often is where most of them end up living forever. I have a lot of great work here, that I easily forget about, shortly after pushing the ideas out of my head, and on to the server via my IDE. 

I have never had a way to index, search, or discover what this wide array of coding projects that I have produce--if a piece of code never gets a link in my administrative interface, it will often be lost forever. Sometimes I will write some code to support an idea, only to find a folder adjacent to it that does the same thing. Doh! I forget I ever did that!

With my new approach to managing my API stack as a series of Github repositories, the ultimate goal of any coding project, is to wrap it as a simple API. As I wrap up any little snippet of code, the final step is always to publish it to an existing repo, or create a new repo, and make sure it is available as a simple API endpoint.

As an API endpoint, in my API stack, every piece of code becomes discoverable via the APIs.json file, which I can browse via the Github Pages portal, or programmatically via its JSON. I'm sure some endpoints I may never use, but at least its available in my toolbox as an API, and who knows I may eventually put it to work, or evolve it as part of some future idea.

I'm already seeing a significant increase in my own operational efficiency because I have my earlier code toolbox available as an API stack.