Is Open Source Dying?

Eweek has a great title, Is Open Source Dying? that's sure to get lots of people clicking. But the article's title should really read Is Open Source Hard To Implement For Government Institutions? They are the only examples provided in this article of organizations having trouble implementing open source.

I expect that large organizations will continue to have trouble implementing open source technologies. The basic problem is that many of these technologies require some real hands on expertise to install, configure and troubleshoot. My experience is that technologies such as Linux, MySQL, and Tomcat include enough documentation and installation scripting to get a system administrator 95% of the way to a stable production environment. But finishing off the last 5% is often less than trivial and can often require some research and tinkering.

A large organization can (and should) purchase support contracts from open source vendors to get help. But I expect that this only goes so far and like the article suggests, even big name service contractors like IBM have financial incentives to push organizations to commercial software. And so does EWeek, afterall, Microsoft, Oracle, and other commercial vendors pay a lot more in advertising than open source vendors.

Is open source dying? I think not - even for large organizations. Everyone is looking for a technology edge on their competition, so one question is, does open source make bleeding edge technologies available to their users faster? I think so. Just look at the number of open source AJAX frameworks and their maturity levels then compare them to the more recent commercial offerings from Microsoft, Adobe, and others. Another question - can large organizations see cost savings by adopting selective open source technologies and deploying them to the most appropriate areas? Absolutely. You can't tell me that everyone in an organization needs Microsoft Office and can't be trained to use a product like OpenOffice.

But the author does conclude the following:

Does that mean open source is dying? Of course not. But the open-source community needs to get over its overweening sense of superiority and messianic inevitability;

Also as important - corporations and their CIO's need to be realistic about open source rollouts. The price of open source is expertise, and you will need some internal experts when you choose to promote one of these technologies into a production environment. You will need time to prototype and experiment. You probably still need support contracts. You should characterize and ideally quantify the ROI. Apply your best practices on selecting and deploying open source technologies as you would a commercial technology.

continue reading "Is Open Source Dying?"

5 Development Tips for the Facebook API

Below are five tips on using Facebook's API. These techniques were all used in TripConnect's Travel Profile Application that allows Facebook users to add a travel interests to their Facebook profile. I know they work in this app, but they may not be the perfect solutions.

The first two tips are specific to the JAVA kit. The others are more general.

1) Installation - I saw several posts in the Developer Forum on users having trouble installing the Java kit in Eclipse. I didn't have much of an issue . All that was needed was to create the com.facebook.api package in the src folder, move all the java files into this folder, drop the two jar files (browselauncher and json) into my libraries folder, add these libraries to my ANT User libraries and build... No issues.

2) FacebookRestClient.java -does not have a method to pull the userid. So after calling facebookRestClient.auth_getSession(authToken) to establish the session, I found no way to get the userid. Odd... All I did was add one method:

public int getUserId() { return _userId; }

to FacebookRestClient.java

3) What to do with the Session id - Store this in your application's session manager, but don't store it forever (e.g., don't store it in the database). You can try to ask the user to 'remember me', but there is no guarantee that the user will do this for you. The JAVA api doesn't gather or store the expiration value for the session so if you want to be slick and test for expiration, you'll need to modify the API to collect it for you. Regardless, if the session expires or you just don't have one for this user, then you need to redirect to

http://www.facebook.com/login.php?api_key=YOUR_API_KEY&v=1.0

as stated in the authentication guide.

4) setFbml - is the call you have to make to set content on a User's Profile Page. We found the best way to set content is to use fb:ref and pass in a URL that you host for the content that you want to display. fb:iframe will not work for the profile object. Note that the contents of the URL that you pass are stored in a Facebook cache.

In the developer's forum, many users have asked about how to update/reset the cache. Some have tried doing this w/ a script on cron and storing session id's. Even if you get this to work (I haven't seen a fool proof approach), you are creating a potential scalability issue if your lucky enough to have lots of users sign up for your app.

The best method is to have the app update the obect if/when users access your app. Facebook provides an Edit Url which you can use to point to a canvas page with links to update the application data. Once the user does an update, your application can reset the cache. Here's how we do it:

• Edit URL points to a canvas page with a bunch of links on tools users can enhance their travel profile.
• Each link points to http://www.facebook.com/login.php ... . The next attribute in the query string is used to point to the tool in the TripConnect application.
  
• Since your inbound links are bouncing through http://www.facebook.com/login.php , you'll get an auth_token parameter which can be converted to a session id.
  
• Once you have a new/valid session id, you can call facebookRestClient.fbml_refreshRefUrl(URL) (which will update the cache) followed by a facebookRestClient.profile_setFBML("<fb:ref url=\"" + URL + "\"/>") (which insures that fbml for the user's profile is set correctly.

It's not perfect but should work in many situations.

5) Your callback URL - The easiest thing to do with the Callback URL is to redirect it back to
http://www.facebook.com/login.php which will give the user the opportunity to add the application. But doing this blindly and without checking the current state can lead to problems. For example, if the user already added the app and an auth_code was passed in, then redirecting back will cause a message to appear to the user - "You already added this app". Our logic on this callback URL does the following:

If an auth_code was not passed in then redircect back to http://www.facebook.com/login.php
else if the user is already a member, then render an appropriate page
else (user is not a member and auth_code was passed in) then send the user to the Add App page. (http://www.facebook.com/add.php?api_key=YOUR_API_KEY

Regarding the last use case - this seems to be either a defect or oddity in Facebook's authentication which can happen if the user adds the app, then removes it, then tries to add it again. Since the user added it once before, Facebook doesn't present the page to add it again.

One issue with the last use case is the add.php is a full page (w/ nav...), but the call to your Callback URL is supposed to return only the content frame. You'll need to frame bust your response using something like the following:

<meta http-equiv="refresh" content="0;url=http://www.facebook.com/add.php?api_key=YOUR_API_KEY"/>
<script type="text/javascript">
if (top.location != location) top.location.href = location.href;
</script>

Updated June 14, 2007: The facebook wiki has updated documentation on the callback URL.

The callback page now does, theoretically, double-duty. In the previous world of the Facebook API, your callback page would get called back when the user visited login.php, and it would be a GET with a &auth_token= (and whatever else you wanted to pass around). If, however, the user visits apps.facebook.com/yourapphere/, then the callback is called to serve the "canvas". In that case, it gets a POST.

See Your Callback Page for all the details.

continue reading "5 Development Tips for the Facebook API"

Review of the Facebook API for Developers

On May 24, Facebook officially released its Developer API. It's probably one of the first (and definitely one of the biggest communities) to open a social network up to the development community. It's also a sharp contrast to MySpace's tactics in blocking widgets (See: MySpace security measure disables viral spread of widgets).

At first, I thought it was just a proprietary widget API. In fact, the most used feature will probably be it's hook for placing an object on a user's profile page. But on closer inspection, you'll see that the API is powerful. You can host 'canvas' pages on Facebook using its navigation and your object pulled from your server in a frame. There are interface points for some transactions like adding and dropping your Facebook application. You can use their markup language, FBML, for publishing dynamic content or query their data objects using FQL, a query language similar to SQL. There are development kits for just about every web development platform.

TripConnect launched its first application this week. Facebook users can add the TripConnect application, register or login with TripConnect and then build a simple travel profile of places they've been, places they want to go, and travel interests. An object on the user's Facebook page highlights their travel profile and a link in the left hand rail shows a page with travel updates. Users can enhance their profile by rating places or by adding reviews. Enhancements are in the works...

It took us just a few days of development time to roll out this application, but we had to wrestle with the API. The API can be powerful, but it looks like it was rushed out the door. There are significant details with authentication, session management, and cache'ing that are not described well in the developer documentation. There are some optional application parameters that have no documentation and several fbml tags are also lacking docs. The JAVA API which we used is fairly complete, but has several quirks you need to work around. Much of this is discussed inside Facebook's Developer forum.

I will post details in an upcoming post, but for now, my advice to those tinkering with this API is to proceed slowly. Prototype out the functionality in small pieces. Document your use cases and test frequently. This is good general advice but since this API is still a 1.0, you have to work around the gaps in functionality and documentation.

continue reading "Review of the Facebook API for Developers"