The ongoing Oracle vs. Google lawsuit is bringing increased focus on the applicability of copyright laws to software and specifically APIs.  At stake is whether a provider can provide an API that “looks like” another.  While you might have already formed an opinion on this issue, it is a good idea to consider the purposes and objectives of a copyright.

A copyright legally protects works of original authorship fixed in tangible form.  For a similar paradigm I think it is helpful to look at the application of copyrights to websites.  In that case, a copyright can be attained to protect the text, artwork, music and audiovisual material, but it does not protect the ideas, procedures, systems or methods of operation behind that website.  Right away, what this tells me is that copyright laws are for content not process.  APIs are written for applications, not users, so while APIs can deliver content that might fall under copyright laws, the actual delivery mechanism is simply a process.  This of course is where patents come into play which is an entirely different form of protection. 

But lets dig a little deeper and not just dismiss this application of the copyright laws so easily.  Looking at the website paradigm a little more closely, this interpretation of the law means that you can’t publish a website that looks just like http://espn.com.  However, you can publish the scores of different games just like that site does.  The same is true of a site that publishes word definitions just like http://dictionary.com or stock quotes just like http://nasdaq.com. 

This is a great precedent that helps us to draw the line between protecting unique content and overzealously blocking innovation.  Consider the following information:

(21-11)Texas 7, (20-12)Baltimore 3

The fact that two teams played a game, each has a record for the season, and there was a final score for the game is not unique content, which is why I can provide this information in my blog without legal ramifications.   I only start to encroach on copyright laws if I use team logos, other protected graphics, or copy somebody’s summary of the game.  Just as a baseball box score doesn’t differentiate one site from another, an API message’s signature does not differentiate it from another.  The real value is in how the provider retrieves, processes, enhances, and/or formats that data, all of which can be protected through a combination of patent and copyright laws that require no reference to the API signature. 

Imagine the consequences if only one company could provide baseball scores on their website or provide a weather forecast through an API.  This application of the copyright laws would limit innovation and provide a barrier to entry that would lead to domain-specific monopolies.  There is a lot of opportunity to add value through the use of APIs, but blocking new entrants for specific API signature would quickly stifle that opportunity.

Day four of Oracle's copyright and patent lawsuit against Google's Android OS brings a lesson in API design and programming that even the judge declares 'confusing.' http://bit.ly/IBHL9N

Ever tried to explain what an API is and does to a loved one, a friend or an investor?  Imagine having to explain what an API is to a jury!  What are your favorite examples of how to explain "What is an API"?

Nuance is a company that's been around for quite some time.

I find it interesting that a change to their API can impact their strategy greatly, yet it appears that will be the case.

In fact, their API strategy is complementing their overall operational execution strategy at the highest levels as Apple appear ready to announce deep Nuance voice integration with the next generation of iPhone.

As with most other activities lately, things are being done faster with fewer people. What better way to understand how your API is being used, so that you can adapt quickly to market signals than to use a tool like theRightAPI for collaboration with your developer community and insight into their activity?

It's crunch time here at OpusGrid. All very exciting (and busy).

So, yesterday Google launched the first Google+ API's. It'll be very interesting to see how it goes. I think there was a bit of a hockey stick adoption to Google+. It seemed to launch great, then adoption seemed to fall off.

I wonder if this was because we were limited to the features and capabilities that Google launched with the first release. Now, with the release of the API we'll see some innovation by outsiders using Google Plus as a platform. This is where the rubber meets the road, and now we'll see if Google+ stands a chance.

I'm interested in seeing if I'm correct, because if I am, it seems that it's no longer OK to launch a product like this without an API. That's some change to proprietary software models which in many ways stifle innovation.

New to Google+? Why not add me to a circle, and let's figure it out together.

Hah! No, it really doesn't.

What it does need are similar capabilities to help companies manage the complexity of integration, even when integrating using standards based service models and API's.

In a very interesting Information Week report on ERP, writer Doug Henschen makes some really interesting points that I believe is a "must read" for companies using API's as a core part of their application/IT strategy and vendors who sell to those companies.

In a section titled "the integration imperative" Doug shares a Starbucks use case. Many who look at that use case would think of it as a mobile application, or even an example of social technologies used for business. Underlying all of that are a few key things, without which such innovation would be impossible:

1. Be willing to deploy pretty good, not perfect, apps. Gen Y and Millenials are used to things mostly working, and getting them faster. As a solution provider, having a solid infrastructure and a good understanding of your data and API will let you be nimble and have short release cycles.

2. API's are a core feature requirements. This report states that 64% of respondents cited easy integration as the most important thing they look for in enterprise apps. That's a huge difference to the secondmost cited quality which came in at 38%. Implied in this, if you are a vendor, is that you deliver an API that people can use easily for complete use cases. Said in "MBA terms" - you need a "whole product offering" around the API. Not just a REST interface.

3. Develop a way to listen and respond to the user community. The report shares an example from Guess, but I'm going to share a personal one. I was once in a Kinko's getting business cards printed, and the guy helping me was clearly having a hard time with his software. Within a few minutes, I was behind the counter, pointing and clicking with him, asking him how IT decided what the software should do, how it was deployed, what's wrong with it, etc. The people that use this stuff actually know something. Now, you don't want to just deliver "faster horses" but you do want to interpret their insights and add value based on your deeper technical understanding of the possibilities. (PS That's a reference to Henry Ford who said something like "had he listened to cusotmers, he wouldn't have created the car but built faster horses.)

It goes without saying that OpusGrid can help with the three key requirements above. Whether you are a small company looking ot use other API's, a cusotmer using services inside your internal integration infrastructure (dare I call that a "private cloud"?), or a vendor trying to make sure you're deliver a whole product around your API's.

Why not check out The Right API, or drop us a line?

I'm assuming most people who read this blog don't live with their parents. Meaning, you've purchased or rented a home/apartment/boat or something. When you shop for one of those, there are "hard" factors - # of bedrooms/bathrooms, size/shape of the layout, amenities, and so on. There are also "softer" characteristics.

Something along the lines of the "feel" of the place, or the neighborhood. If asked, maybe you could mention some hard factors that impact the feel - the lobby was dingy, or the doorman didn't make eye-contact. But, it's more than that. Imagine a fresh coat of paint in the lobby and a doorman with a smile. There'd still be something.

It's the way we take in information.

By the way, it's the same thing with dating. Ever meet that person who was "great on paper" but, still, you just didn't feel it?

This is the unnoticed problem with consumerization of IT. Because, just like the building manager who could clean up the lobby and tell his employees to smile, he'd still have a building with a bad feel.

In my opinion, that feel is the result of an aggregate of issues that individually are small, but add up to more than that collection of the issues themselves.

Some companies are starting, as a result of their falling behind consumers, to have a bad feel about them. Especially from the perspective of their target consumers/employees.

Companies are falling behind the consumerization curve, and it's not good.

IDC just published a study on the topic of consumerization. They make 3 key points:

1. Consumerization is driven by users

2. IT is not, for the most part, embracing the trend

3. Consumerization is accelerating

On the surface, they're talking about using iPhones, iPads, and Android devices. Consumers have access to these devices, and many companies don't. I worked at a bank for a short time, and we didn't even have laptops! Honest to god, I couldn't figure out how to change my personal work-flow to be in one place with my computer to get my job done. I need to communicate with people, and that means going to them... and my computer is a tool to communicate. It's inseparable.

However, consumerization is more than about some flashy devices, or the convenience of carrying one device instead of two. That's like saying you buy/rent the biggest apartment, or the one with the most bedrooms. You don't. You pick your new home because it's the one that meets your requirements and feels best.

Every marketing person knows this. I recently bought an engagement ring (yes, congratulations) and there were tons of gorgeous rings in my price range. We bought the one where buying it was a great experience.

What am I getting at? Here it is...

Consumerization is about the feel of a company's infrastructure. Technology should be invisible. It's woven into our lives these days, and companies who look like they've not left the 80's are going to look just as silly as someone walking around with a mullet today.

The trend to rapidly develop good-enough solutions using internet-accessible API's has set the baseline. Most people don't realize they're "good enough". So, for example, when you have to sign in 10 times within your company's firewall to access all your applications... people are going to ask, why not just use Facebook, or Google, or Twitter. They've all solved the problem for their communities?

Companies infrastructure are not only missing key features... they feel like they're stuck in the 80's. And, that's bad for companies trying to win the best projects or attract the best people.

Would you do business with a guy in a mullet?

Would you date a guy (or girl?) with a mullet?

Would you go work for a guy with a mullet?

Maybe, if their "stuff" were so compelling. But, you know it's extremely competitive out there today - on every front. It's competitive to hire the best employees, to win the best projects, and to stand out from the mess of options we're all bombarded with daily.

Knowing this, why are you showing up in a mullet?

Companies need to figure out how to use API's, while incorporating as much of their enterprise class requirements (that most users don't understand) as they go. They've got to figure out how to minimize risks, and recognize they won't ever eliminate them. Then, they need to work with employees to meet them part-way. Deliver some of what they're asking for, and at the same time educate people about the risks and limits companies face that are different than "internet API startups". You'll find the dialog will benefit you and your company in more ways than you could imagine.

Last week was a real milestone for OpusGrid at GlueCon2011 as we publicly unveiled some of the capabilities we have been working on over the last several months.  With the launch of theRightAPI Beta, we have introduced the first couple of steps of the API lifecycle:  Discovery and Evaluation.  The buzz and feedback that we received from several attendees was truly exciting as we talked about the unique approach we are taking in providing quality information to API developers and decision makers that can help them be more productive more quickly.

On Thursday, I had the opportunity to participate in an “API Perspectives” session with Steven Willmott of 3scale and Jeff Hoffman of enStratus.  We each offered our thoughts on a particular area of the API industry that requires some attention to continue the success and maturation of APIs.  I chose to speak on the overall need to establish trust between API consumers and providers.  I believe the message resonated well with the audience as I spoke to the need for 1)visibility 2)accountability and 3)time to achieve even an acceptable level of trust.  One without the others will only provide limited benefit to the overall ecosystem, so simply hoping that time will lead to increased trust is truly a naïve presumption.  Today, there is too little visibility into APIs, their performance (good or bad), and any changes they make.  If APIs are a moving target, additional time will actually erode any existing trust, not increase it.

This is why we launched theRightAPI first.  We see it as the first step in establishing a robust API ecosystem that brings consumers and providers together.  However, it is also just the first step as we will continue to increase the information and capabilities provided through theRightAPI to enhance the discover and evaluation of APIs for your applications.  Please register on the site and continue to follow OpusGrid as we provide updates on our progress.  We have a Feedback link on the site, but as always feel free to contact me directly at williamo@opusgrid.com if you have any thoughts or suggestions.

As the details of the Amazon outage last month come to light (kudos to them for being so forthcoming), we should all be reminded that the cloud is not an opportunity to shirk our responsibilities as architects and systems engineers.  The only computers or software that can even theoretically attain 100% uptime would be those that are completely isolated from any changes.  In other words, no people could modify them.  It would be foolish to think that moving to the cloud allows us to ignore that fact.  Amazon is simply the latest example demonstrating that people can do a good job of planning for computer errors, but computers are very poor at planning for people errors.  

[Aside:  If we could ever create a computer that overcomes this, we might just be in trouble.  While I think the Matrix went a bit too far, a computer that could correct all human errors starts to look a lot like Skynet.  I’m not convinced that its possible for us to build something that intelligent or impenetrable, but we do seem to be getting closer all the time.  Ok, back to the here and now led by us flawed humans…]

Anyone that moves to the cloud must recognize that human errors can bring computers and software down whether they are in the cloud or your own data center and plan accordingly.  To borrow a familiar saying, there are two types of clouds: Those that have had outages and those that will have them in the future.  As with any kind of high availability plan (or stock portfolio), your best chance at mitigating risk is to diversify.  Like any other environment, you must understand where the outages can occur in the cloud and build in your own safeguards.  In some cases this may mean leveraging multiple data centers across the same provider.  In other cases it may require you to leverage multiple providers.  This is something that we have been thinking about a lot at OpusGrid as we get closer to our first launch (stay tuned for an announcement next week )

While the cloud can provide a tremendous value proposition, it is still a system that can be brought to its knees by the right change under the right conditions.  As long as people are in control, that will continue to be the case so you better expect and plan for those scenarios if you can’t afford that margin of error.

I had the opportunity to sit in at a Meetup in NYC the other night for building an e-commerce site based on WordPress. There were speakers representing 3 companies that provided out-of-the-box e-commerce integration to WordPress.

The first two vendors talked about their e-commerce plug-ins for WordPress. During these I was categorizing the pros and cons in my mind, and I started to wonder.

Did either of these plug-ins offer an API?

It would be interesting. I'm sure someone would want programmatic access to the information and capabilities. What would the architecture look like, and how would WordPress handle being an API end-point?

Then, the third solution was presented. Ecwid is a hosted e-commerce offering that integrates with WordPress and many other platforms delivering a single e-commerce hub that is consistent across all a vendor's storefronts.

And, Ecwid has an API.

Ecwid compares to the other offerings in that it's not a WordPress plug-in, however it does offer a major advantage to e-commerce shops:

E-commerce stores that don't have the technical expertise and infrastructure to host an API on their storefront can still get/give scalable and robust programmatic access to their shopping infrastructure.

I'd say that's pretty differentiating.