Friday, May 23, 2014

One Characteristic Of Many Of The Enterprise API Folks I Meet

When I run into enterprise folks at events, one of the common characteristics I notice, is they always tell me how much they read my blog. Yay! Many of these people have Twitter accounts, which follow me and I follow them, and they can usually reference specific topics or posts I've written—demonstrating they do indeed read.

Most of these people I'm aware of online, and I usually consider them fence sitters. They rarely retweet posts, or engage in conversations online, they just consume. I think this is fine, because not all everyone is suited for actively engaging in the social media world. What I do think is interesting is how interested they are in my work, and they let me know how my work reaches them, and reference specific topics and stories, but don’t actually contribute to the conversation.

In my opinion this isn't individuals faults, this is enterprise culture. Businesses of this scale are not equipped to deliver value unless it is sanctioned and specifically part of the larger brand. The enterprise generates value, but only when in service of their business objectives. Generating open value for a community, even as small as a retweet, comment, or a response in blog post, is not in the DNA.

I strongly believe that businesses should generate just as much value as they consume. I’m not stupid. I understand that capitalism is about extracting value and monetizing for shareholders, but can’t help but think about what this existence is like for these individuals.

Personally, I find it very rewarding to contributing to communities, and the overall health of the API community, by contributing ideas, engaging in conversations, without the expectation that it will all result in revenue for API Evangelist. Ultimately all of this effort comes back to me, and ensures I will be able to sustain my evangelism efforts, while also nourishing my own individual needs.


Wednesday, May 7, 2014

Partnering For Me Is About Sharing Of Ideas, Research and Stories

I just turned down a potential partnership with a major enterprise company. As I do with many stories, I will scrub the names of those involved, because there is no reason to blame a single company, this is a lesson any large entity can learn from—for this story, we’ll just call them Acme Inc.

Acme Inc. contacted me a couple weeks ago, stating they were looking to do some research into the API space, and have been following my work for some time. After a few emails we made time to get on the phone and talk about what each of us were up to.

We spent about an hour, where I gave my history, why I do API Evangelist, and how I go about generating short form, and long form content as part of my research across the API space. Acme Inc. shared their interest in exploring how APIs could be applied to a couple of business sectors, and were looking to generate white paper(s) that they could distribute internally, and amongst partners.

Acme was extremely vague on details, and I understand that not everyone can be as open as me, especially when you work at a big company. We ended the call, agreeing that we’d explore what a potential partnership might look like, around research projects, but they would need me to sign an NDA first—no problem.

I received an NDA via email a couple days later, as I was on my way to IBM Impact in Las Vegas, and while I was busy in Las Vegas I received an a reminder to please sign the agreement. When I was done in Las Vegas, on my way to Texas for another engagement, I signed the NDA, printed a PDF and sent it back. A few days later, as I was leaving Texas, on my way home to LA for about 8 hours, before I left to Berlin, I received another email requesting that I sign a second NDA, this time using a digital signature solution.

At this point my inbox was already out of control, and I boarded the 12 hour flight Berlin, and proceeded to gear up for APIDays Berlin. After a day in Berlin where I finished my talk (which I rewrote onsite to better suit the local audience), and two days of the amazing interactions at API Days Berlin, I finally made it back into my inbox.

This time I found another reminder, to sign the digital copy of NDA. At this point, I’ve received 2 separate NDAs, and two reminders to please sign the NDA--ith no knowledge of what the ideas are. Maybe these are ideas or research I’m already working on? Who the fuck knows!

I just sent an email to my Acme representative, stating that I will regretfully decline the partnership, and summarized my feelings. Acme thanked me.

With this response, I probably blew off thousands of dollars in revenue, and who knows what else. In the end I don’t give a fuck. What I do is not about revenue or showcasing partnerships with global companies. It is about ideas, research and my storytelling, whether it is short form (blog) or longer form (whtie papers), or in person, and always in a way that provides value to the community.

I understand that a large entity cannot operate like I do--I’m not naive. However when it comes to the world of APIs, if you want to play, you have to learn to open up, and at least be able to have conversations without the need for an NDA. People in the enterprise might fuck you over at every turn, but I do not. You can ask me to keep something private, and I will—end of story.

This is the fundamental difference between APIs and SOA that so many enterprise practitioners do not understand. As an individual I am so much happier being able to openly share my ideas, stories, code, and other resources publicly, in a way that is openly licensed, and most importantly—accessible by everyone. I strongly feel that there is a lot for the enterprise to learn from the world of open APIs, which isn’t just about technology. However, I’m gambling that most of them will never give a flying fuck.


Thursday, May 1, 2014

APIs, edX, Tableau, Google At UT Arlington

After I went to Emory University in Atlanta, and spoke at IBM Impact in Las Vegas this week, I attended a one day of a planning session for an edX course at UT Arlington, in Texas.

George Siemens (@gsiemens) invited me out to for the planning session, which included folks edX, Tableau, Google and of course UT Arlington. I gave a one hour talk on APIs, a talk I had originally prepared to be about APIs in higher education, but after listening to the discussion for a couple hours, I crafted an entirely new talk.

The planning session was called "DesignJam for edX MOOC on Data, Analytics, and Learning”--which was all about developing an online course around data and analytics, where pulling information via APIs would play a central role.

Originally I was focused on evolving the edX platform using APIs, something I will be exploring more after talking with the folks from edX. However, in the end, I focused on how we could teach hundreds, or potentially thousands of students, about using APIs as part of a wider data and analytics class.

The session at UT Arlington ended up being a great experience, thinking about the potential of APIs for edX, what a class about data and analytics using APIs would look like, and a full day of hanging with some really interesting academics, while getting an opportuity to observe the process around planning in this fast growing world of online courses.

Just like with the domain exploration at Emory University, experience at IBM Impact in Vegas, I have a lot of notes to process, and I’m sure I’ll have more to say about what happened in Texas.


Exploring The Domain Universe At Emory University

When I say the word “domain”, what does it conjure in your mind? Most likely if you are in the tech space, or adjacent to it, you think of a Internet domain like "". A virtual address you can use to point to different resources on the Internet, like websites, applications and APIs.

If you rely on the dictionary for your answers, you will get:

an area of territory owned or controlled by a ruler or government
a specified sphere of activity or knowledge
a discrete region of magnetism in ferromagnetic material

With synonyms being realm, kingdom, empire, dominion, province, territory, and land. We have thousands of years of history to help define what a physical domain is, something that is still being defined as time marches forward. However we are just getting started when it comes to defining what a domain means in a virtual world.

I spent Friday and Saturday last week at Emory University in Atlanta, at the Domain Incubator, where I spent two days with some seriously smart academics, exploring the wide, and expanding universe of our physical and virtual domains, from the perspective of an educator and student.

There were a number of amazing talks, and keynotes from Audrey Watters(@audreywatters) and Jim Groom(@jimgroom), all of which Jim sums up nicely on his blog. This conversation is born out of the Domain of One’s Own Program out of University of Mary Washington, Reclaim Hosting—something Emory, and other universities are adopting, and following UMW's lead.

In the coming years, I’m looking to define my own online and offline domain, but shifting my focus from pure API Evangelism to a more reclaim your domain approach, helping individuals, businesses and organizations define and reclaim their domain, in this rapidly expanding online world.

My head is still swimming from all the events I participated in over the last week, so I’m sure I’ll have many more thoughts as I decompress, and go through my Evernote. I'm really excited about the potential of reclaim your domain, and programs like domain of ones own, but what really gets me going is that this is coming out of leading higher education institutions, led by some seriously smart, and passionate education professionals.