With my new work at i.TV (go visit the iTunes Store Home Page if you want to try us out - lower right-hand corner), I have started phasing out my consulting (which used to be my full-time job) and am putting my focus towards building (with a top-notch team and great CEO, of course!) one of the top Entertainment App companies out there. In the process, I am still getting 5-10 people a week contacting me asking if I know anyone that does iPhone or Facebook Development. Quite frankly, finding someone to refer to is not an easy task! That is what I used to do, so it wasn’t something I was looking for (and I know there just aren’t many out there, as well, even with the high demand).

So, if you or someone you know does either iPhone or Facebook development, or work for a company that does, I want to make a deal with you or your company. I’ll send you these referrals for a commission on the deal you make with them. This is a win-win for all - I now have someone to send referrals to. You get the referrals and regular business, and the Clients now have someone they can get help from. Having written books on Facebook, and working for a company that does iPhone App development, along with this blog growing considerably and guest blogging on some of the top blogs on the internet, I get these requests regularly - I’d really like someone to send them to.

If you’re a developer, perhaps you’re starting to see the demand of Facebook and iPhone development. This is an excellent area to have knowledge in, in particular in a down economy. If you’d like to learn I do recommend you look at my book, FBML Essentials, and at the end of this month I’ll be doing a free webinar for O’Reilly in which I’ll cover beginning Facebook development. Stay tuned to this blog and I’ll reveal more details soon.

Know a Facebook or iPhone development company or developer? Shoot me an e-mail (or comment below): jesse at staynalive dot com or call me at (801) 853-8339. Also, if your business is in need of such work, give me a ring and I’ll point you in the right direction!

Facebook developers are reporting 20-50% drops in their Application traffic due to an unannounced deprecation of the old apps.new.facebook.com URL by Facebook. Over the weekend, Facebook appears to have deprecated the apps.new.facebook.com domain, but some developers are reporting that users aren’t recognizing the new domain, apps.facebook.com, causing the drop in traffic.

The apps.facebook.com domain is the central location for all applications on Facebook. Developers are given a unique suffix to the apps.facebook.com domain, giving apps.facebook.com/appname a unique location for every application on the Facebook platform. Facebook created the domain, apps.new.facebook.com to accommodate apps trying to test in the new design as it was in the process of being released. Now that all users should be transitioned to the new design, it appears that Facebook has decided that the two URLs are no longer necessary.

Facebook (perhaps not as often as Twitter) is known for changes like this. While it’s been awhile, the early days of the Facebook Platform were prone to frequent changes by Facebook with little notification by the company. For this reason, Facebook implemented a beta testing ground before pushing changes so bugs like this would be revealed, but it appears Facebook is not using this testing ground in all cases. As one developer put it, “I was planning to go on a sailing trip today, but when I noticed all the problems had to cancel that to fix all the absolute urls I had.” Unannounced changes like this, with little testing, are bound to cause developer frustration and angst as we’re seeing now.

Facebook has put in place a Status Feed to announce such things, and just last week announced that over the weekend the new “api.new.facebook.com” would point to the same place as “api.facebook.com”. Being a backend process, Facebook mentioned nothing about a deprecation of the apps.new.facebook.com domain. Also, any user that previously had an apps.new.facebook.com domain bookmarked will now be sent to a 404 not found page.

We have yet to hear an announcement by Facebook on this matter.

UPDATE: For some reason the link to the forums above has been removed and the post is gone. The text of the main link is below (written by crimson), followed by a long list of other developers seeing the same thing:

I’ve been doing some testing with the recent DNS errors and it seems that for most users, apps.new.facebook is broken. It’s sporadic though, and only affects certain user accounts at random times. I haven’t heard any complaints about apps.facebook.com being broken though, so I would suggest putting a message on your about pages asking users to go to apps.facebook.com instead of apps.new.facebook.com. If you have any absolute links to apps.new especially in notifications, newsfeeds, or notifications, you should also get rid of those immediately since it will cause your users to end up on the new domain, which will rewrite all urls from apps.facebook.com to apps.new.facebook.com, and can lead to further problems.

It’s so annoying that Facebook decided to do this over the weekend, which means we have to work also on the weekends. I was planning to go on a sailing trip today, but when I noticed all the problems had to cancel that to fix all the absolute urls I had. I found I’m losing anywhere from 20-50% of new users simply because of this issue. It also seems that at times only apps.new.facebook is broken, and not www.new.facebook. Hmm, talk about double-standards.

UPDATE 2: Facebook appears to have fixed the problem - when I checked today, apps.new.facebook.com was again correctly redirecting to apps.facebook.com

UPDATE 3: It appears other developers are still seeing the issue, still no word from Facebook: http://staynalive.com/articles/2008/10/06/facebook-dns-blunders-take-down-obama-app/

Regardless of any complaints from developers surrounding the new Facebook platform redesign, many developers are seeing success. Looking at various statistics from sites such as Adonomics and the Facebook Developers Forum, it appears that those apps that are truly integrating the new Integration points that the Facebook Platform provides are truly seeing success with it. Those apps that remain stagnant will see a decline in behavior.

Apps That are Seeing a Decline

Reviewing the apps complaining of the new design and showing declines in their numbers, it appears that many of them aren’t integrating into the new design where they are supposed to. I’ll use my own app as an example. “We’re Catholic!”, one of the religious apps I wrote and run (I also run “We’re Baptist”, “We’re Protestant”, and wrote the app, “The LDS App”) at one point was getting up to 1,000 visits per day (DAU’s, or Daily Active Users) as it was taking off (it is still currently the largest single group of organized Catholics on Facebook). Users began to get used to the Facebook platform, and that leveled it off to about 2-300 DAU’s per day. At launch of the new design, that number has gone down 1-200 DAU’s per day. What’s not being told in this picture is that I have done absolutely nothing to integrate it with the new design due to lack of time. I have no doubt that with a little integration into the user’s profile with a tab, and maybe info section, along with some Feed Forms to give users the option for larger stories to share with their friends from the app, I could very well see my app stats increase to even more than they were before.

Pieces of Flair

This seems to be the issue with some of the apps developers are complaining about. One example pointed out in the Facebook developer forums is the Pieces of Flair app, by RockYou. Looking at Adonomics statistics, it appears on September 4, the week the new design was put in place, Pieces of Flair took a dramatic turn from near 660,000 Daily Active Users down to around 350,000 DAU’s in just a matter of a day. They were stuck there until September 16, where their DAU’s went up to 570,000 in just a day, still far short from the 660,000 DAU’s they used to have. Then, on Sept 18, the DAU’s went back down to around 400,000. Looking at this statistic, it would appear that Pieces of Flair isn’t doing very well, and that the new Facebook Platform redesign is to blame. To know for sure though, you have to look at the timeline of events related to the App.

Facebook Platform Timeline

September 4th, 2008 - New design launches to all

Looking at the history of the new design rollout, the new Facebook redesign was rolled out right on the week of September 4th, which would make the sharp downturn very understandable. At that point users were getting used to the new design and learning where things were.

September 10th, 2008 - Applications link moves

Right around September 10th or 11th it seems Facebook moved the “Applications” menu from the top down to the lower-left panel on Facebook. In addition, users could “bookmark” their favorite apps. Could Pieces of Flair have been one of those users were bookmarking? Other apps were bound to have seen a decrease because of this change.

September 16th, 2008 - Pieces of Flair makes changes

September 16th took some research to figure out. Looking at the forums on the Pieces of Flair About Page, several users started commenting about how it was now possible to add the app’s profile box to their “wall tab”. It’s unclear if they added a specific application tab at that point or not, but there was definitely an increase at that point, and it looks like it may be because of a change put in place to adapt to the new design by Pieces of Flair.

September 17, 2008 - One-line feed stories consolidated

On September 17, Facebook consolidated one-line feed stories that happened frequently for a single user in a day into one item in a user’s news feed. This would have reduced the visibility of some apps that updated frequently, perhaps explaining the slight decrease on the 18th.

Is it a Facebook Problem?

So, analyzing by date, it would appear that the biggest drops for Pieces of Flair may just be that Pieces of Flair wasn’t yet built for the new design when it was rolled out to members. Perhaps the new design isn’t to blame, but rather unpreparedness by developers of apps that are to blame for the decrease in traffic. Facebook announced the new design back in May, and developers have had since then to prepare - it would seem that this is a developer, not Facebook problem.

Apps Seeing an Increase

Regardless of the complaints, there are apps seeing an increase. While names weren’t mentioned, several developers in the Facebook developer forums posted stats that show such. Even Pieces of Flair we see is starting to show a gradual increase since feed stories were implemented.

We’re Related

Some have shown significant increase though. One of the most significant is We’re Related, which went from 180,000 DAU’s to 460,000 DAU’s when the Applications menu was moved, an all-time high for them. It seems the only decrease they ever saw was right after the redesign was launched. Some developers are claiming they’re spammy, but based on the stats in association with the time-line it appears regardless of spammy measures or not, they’re increasing because users like them and are bookmarking them as a favorite - they shot up more than any other on the date Facebook implemented bookmarking. (disclaimer: they were a client of mine and I trained some of their developers and helped design their initial release, so there is some bias there, but the stats do coincide with what I’m saying. I hold no equity in the company.)

Texas HoldEm Poker

Also of note is the Texas HoldEm Poker game. One of the most popular apps on Facebook, it would seem they too have never seen much of a decrease in usage. They too saw a slight drop after the redesign, but, while not as significant as We’re Related, they are definitely higher in DAU’s than ever before.

WaterCooler, Inc. and (lil) Green Patch

Some other Apps to look at are WaterCooler, Inc. (a conglomeration of many smaller apps), and (lil) Green Patch, all which have continued to show an increase, even after the new design. Of course, Facebook’s native apps have also shown significant increase after the new design, but they may be the exception in the fact that they get special promotion by Facebook in areas developers do not have access to, and are default for many people on Facebook.

Reasons for the Increase

As “DesignerMichael” put it in the Developer Forums, “The golden days will return in about a month though by my estimate. Users will finally start getting used to the new platform again by around then… So all is well. smile Just no more ridiculous changes please… Changing the location of bookmarks once a week is not good for apps. lol…”. It appears, based on the common drop amongst all the apps, that the major issue for developers is that users just haven’t gotten used to the new design yet. Assuming Facebook does not put any more changes in place, things will get back to normal.

In a communication via e-mail with Facebook, I was given the following message about the current state of the platform:

“We’ve seen a number of areas with greater engagement and sharing across the site, both on our own applications and on Facebook Platform. Daily and weekly active usage for applications have been on a healthy growth track for the past six months. Since the cut over began, aggregate Platform usage has continued to increase. The apps that have made the greatest effort to take advantage of the new integration opportunities are starting to see the results.”

Facebook is monitoring this. Without their developers, Facebook is not nearly as powerful as they are now. Currently developers are doing the marketing for Facebook and I’m sure Facebook recognizes that. However, it appears that in the end, as we see with the success of those apps that are seeing an increase, that it involves some work on behalf of the developer to happen. Some areas Facebook suggests are bringing more traffic to apps, or have the potential to do so are:

• Deeper integration into the profile
• Greater distribution through feeds
• Easier for users to discover new apps
• More meaningful user engagement
• Customized application tabs

For developers of apps, you can bring your application to even higher Daily Active Users than before by simply finding new ways to integrate with the different points mentioned above. It is very possible to be successful on the new design, and now is the opportunity for new developers to come forth. We’re in a new race for popularity, and those apps that embrace the new features most will see the most success.

In FBML Essentials (O’Reilly), I cover some of the points of the Facebook platform new design components. You can purchase and review it here on Amazon.

I am looking for examples of companies and developers actually having success in the new Facebook design. If your app, or the app of someone you know on the Facebook platform is having proven results as a result of the new Facebook design, or if your traffic has not decreased from it, I want to hear from you. Those that respond have the chance of being featured here or as a guest post on LouisGray.com. Please feel free to share in the comments or send me an e-mail at jesse@staynalive.com with your stories. I want to hear from you! (And, please share this with others you may think would be in the know - this is a great opportunity for some exposure for your Facebook app!)

I recently covered 5 general features most people may like in the new Facebook redesign being rolled out to all last week and this week. One of the biggest complaints of the new design is that it is bad for developers, reduces traffic to apps, and discourages users from using apps they have installed. While this is true for apps that haven’t adapted, there are still some very good features introduced by the new design, that, in my opinion, bring even more integration points to developers, and allow for more creativity to developers while still maintaining the user experience. I’d like to cover 5 of my favorites.

1. Your Application Now Gets an Entire Tab on the User’s profile

While profile boxes still remain, developers now have an additional option to create an entire tab devoted to your app on a user’s profile page. While you can’t advertise on this tab or monetize it in any way, the user profile page is the most traffic’d page on Facebook, and if you can grab a user’s attention by offering a little more information about your application and about the user themselves, other users are much more likely to engage and use the parts of your application you can monetize. More space to do this is a good thing, and the tab appearing on a user’s profile makes it appear as though your app is actually a part of their profile page. Consider this one giant advertisement for your application.

2. You can now allow users to share additional information about themselves via your application

Some of the most successful applications on Facebook are those that allow users to express themselves in certain ways. Applications that can allow a user to share more about themselves tend to be more engaging, and have a much more likely chance of a user sharing that application with their friends. Let’s face it - the days of an app spreading itself due to the new nature of the Facebook platform are long gone. Now, it is the developer’s responsibility to employ traditional marketing techniques to get the users to share these applications with their friends themselves.

The “info” tab is one way they can do this. Your application can give users an option to click on a simple button that allows them to add additional information to their “info” tab, provided by your application. Again, the profile is the most traffic’d place on Facebook, and this is an excellent way to get your app in front of a lot more people.

3. The new design is more organized, therefore giving your app more potential to be “one of few”

With the new design, most applications get organized into a “Boxes” tab on the user’s profile. This requires an additional click to learn about a user’s applications that they use. However, for applications that enable it, a user can optionally add any of those application boxes to their “wall” tab, putting it among just a few of their favorite applications for their friends to see and use.

If you can create an application that users will like, use, and want to share with their friends, the chances of your app appearing among those few are greater. I don’t have any numbers, but I really think there are only a few applications utilizing this feature right now, upping your chances even further of being one of those users like to feature on their “wall” tab. To me, this actually makes the potential for your app being successful even greater.

4. There are now 3 types of News/Mini Feed items your application can post

While your application can’t necessarily force news feed items to Facebook without the user’s explicate permission any more, you can utilize “feed forms” to allow the user to share one line posts to their mini feed, small summaries to their mini feed, or an entire story to their mini feed. If you can make your app useful enough to encourage the users to share the larger feeds (which were not available before), your app has a far greater chance of getting in the face of your users’ friends, encouraging even further virality. Not only that, but good marketing shows that when a user actually wants to share something, their friends are more likely to listen and participate. Giving your users choice is a very good thing, and will result in a much more devoted audience in the future.

5. With the new design, you can now deploy FBML, right in an iFrame

A new feature established in Facebook Connect enables any website to utilize the Facebook Javascript Client Library to allow a developer with an app set up to parse and load FBML on any page on the web. This means that you can now load FBML right in your iFrame’d pages.

Why use FBML? FBML will guarantee, as Facebook changes their look and feel, that you don’t have to change your look and feel with them. It all happens automatically. Before this, Facebook required all FBML to be loaded and parsed on their servers. Now you can load it directly on your own servers, which means greater flexibility with Javascript, more options when integrating with other platforms like OpenSocial, and less coding overall since Facebook takes care of the details for you. Best of all, you can implement this on any website, even outside of Facebook, and with Facebook Connect, you can even authenticate and retrieve data from Facebook for users, right on your own website! You can learn more about FBML via my book, FBML Essentials (shameless plug).

While I understand the frustration of developers with the new design, and especially the fact that applications aren’t quite as in-your-face as they used to and can’t do things as easily on behalf of users, overall I think this is a good thing for the overall Facebook experience. Now Facebook has provided more integration points for developers than ever before, while at the same time making the experience better for users, making users want to continue coming back to the network. Users coming back is always a good thing for your application on Facebook.

What are your favorite features, as a developer, within the new design?

There are rumors that Facebook has been working on their own Wordpress plugin for Facebook. This is troubling for those of us developers that are developing for Facebook Connect, as it shows that Facebook could in one sweep, wipe any developer writing for the Facebook Connect platform out without any advanced notice. It only appeared that in the past, this type of thing only happened on the Facebook website itself, as Facebook has a right to, but I’ve seen it myself with my own development on Facebook Connect today.

Fair enough. I like competition, although I’d love this to be a community effort. So, since we know Facebook is working on their own Wordpress plugin for Facebook, and we know Facebook isn’t willing to divulge their code yet. Since I’ve already devoted 20 or so of my own hours to the exact same project with no knowledge from Facebook, and am just now learning that Facebook was working on this behind the scenes incognito with no involvement from the community, I’d like to release my own plugin to the public, under the GPL v2.0 today, in the hopes the public can help with development and further building of this plugin, as a community, not just under Facebook’s roof.

It’s very troubling to see Facebook develop on external apps outside of Facebook like this - it only shows that Facebook is not afraid to encroach on other developers’ projects and that any one of us is at risk of having a useful project, our time and effort (I had no intentions on making money from this), wiped out in an instant. Sure, Facebook has every right to compete, but the least courtesy of notifying developers it already knows would be competition. With such a Wordpress plugin this also encroaches on Six Apart’s announced integration with Facebook Connect, and puts Facebook in direct competition with Six Apart instead of making it Automattic’s problem.

It’s my sincere hope that Facebook decides not to continue such projects internally, but instead contributes to existing projects if they must do so. Facebook should in no way be competing with the developers that use their platform without warning, or risk us not being willing to contribute such things in the future. Let’s work together on this Facebook - how about a “we need help” board, or an “internal projects” board so we can know what you’re working on in advance. In this way we can work with you instead of parallel to you and hours spent doing so won’t be wasted. Or how about a little nudge to people like Six Apart saying, “we may just have to compete with you on this in the future” so their own time isn’t wasted with the integration.

Why should I keep building external web apps that integrate and send users to Facebook if Facebook is just going to replace my web apps in the end anyway?

So, I’m going to release my code here right now in hopes we can make this a community project - it requires you to set up your own app for your blog under the Facebook Developers site (just set your callback URL to your own website’s URL), and you must take your application key and enter it into the admin section. Only developers of the Facebook app itself can login through Facebook Connect until Facebook launches (one more advantage Facebook has over us developers - they know when they are launching, and therefore know how much time they have to develop these things, another reason to leave it to us developers in order to keep it fair). To install on your blog after doing so, just unzip the folder in your plugins folder, and activate your plugin under the plugins section in Wordpress. After that, any Facebook user will be able to leave comments, under their own authentication, Facebook avatar, and name without having to re-enter it each time. We’ll be integrating this more in the future - if you can help please let me know! My project is a community project, not owned by Facebook, completely owned by me and you for the benefit of the community.

You can download it here.

You can see it in action on my test site, http://socialmediacast.staynalive.com - check out the Hello World post to see the existing comments. Note you will not be able to log in to Facebook Connect on that site because you are not a developer on the app for that site.

Now, I know I ranted a bit - it’s late, but I hope this makes some sort of sense. Am I out of line here? Should I just scrap my code completely and let Facebook do this? Is it a wise move for Facebook to keep making external apps like this that integrate with Facebook? What’s the best way for Facebook to approach this? I welcome your comments below.

Last week I spoke about how the ‘@’ on Twitter and other microblogging services may no longer be necessary due to the addition of the in_reply_to_status_id API call on services like Twitter and Identi.ca. In the comments of that article you mentioned several examples why that would still be necessary. I’ve spent the weekend contemplating these and still argue with a proper infrastructure these would not be necessary. In my own opinion, services like Twitter and even Identi.ca are broken because there is no easy way to tag individuals and people without cluttering up actual content with unorthodox, unorganized ways of tagging data and people. We, the users have had to come up with our own ways to do so socially, and I think that’s a hack. Let’s go over a few:

Addressing a specific person or group of people publicly.

With current infrastructure on microblogging platforms, this is the one problem that will cause people to continue to need to use the @ sign. There is no easy way currently to say you want to make sure a particular individual or group of individuals see a specific message. This is different than a reply which the recently added API calls resolve, in that these types of messages are not necessarily in reply to anyone. So instead we have to clutter up our posts by prefixing our post with the intended recipient at the beginning, whereas if a proper infrastructure were provided, we could focus solely on the content.

Facebook has overcome this pretty well with allowing you to “tag” individuals in a Facebook Note that you would like to see the message, or that might be in the message itself. Twitter, Laconi.ca, and others need to look into a new API call to allow users to tag other individuals so this is no longer needed. Imagine, for instance, if Twhirl let you choose from your list of friends and tag them in the post you are sharing. You could then have pure message in your 140 characters and not have to worry about the intended audience.

Common English (or your language) names

I mentioned before that @ wasn’t necessary, perhaps even if there weren’t an API call provided to link replies. Microblogging clients should be able to read each username and look at your friends, and tell immediately that you are referring to one of them, adding them to your list of replies.

However, this gets tricky when you get to someone with a username that is common English or even another language. For instance, what if my username were “stay”? Every time any of my friends said they were “stay”ing somewhere I would get a notification stating they were replying to me or addressing to me.

The solution for this again would be fixed with a simple person tagging system like what I recommend above. Allowing me to specify the intended users in the message would allow clients to know I was addressing those users without me having to further clutter up the actual message with meta information that doesn’t need to be there.

Hashtags

Hashtags need to be gone, plain and simple. All Twitter and Identi.ca and even FriendFeed need to add is a simple meta layer to their API, and beyond just allowing me to tag individuals to my messages, allowing me to add tag keywords to identify my message and make it more searchable. Tags clutter up our messages as well and keep us from being able to say what we need to say in 140 characters. In fact, I argue that meta layer should be completely flexibly - imagine if I could append whatever I wanted to a message. Location information, what I’m eating at the time, websites I’m surfing, etc. (I’m just listing those in theory - those could be messages themselves, but some are meta information) Part of our 140 character message should not be words not pertinent to the intended message itself.

SMS and XMPP/Track

So you ask, if we add a meta layer on top of all this, how can I then tag my messages and tag people in my messages via SMS or XMPP (Jabber)? SMS and XMPP should be treated as clients. The SMS client should be just like any other GUI client out there, just text based. I should be able to type “help” and have it give me a list of commands I can type to make it do what I want. Part of that client could be to include #hashtags and @intended’s to specify meta information about the message, but those should be part of the additional 20 characters SMS gives me outside of the 140 Characters microblogging requires. All of the same goes for XMPP. XMPP could provide an even richer experience since it isn’t bound by the 160 character limit SMS gives people. For a great example, see Dustin Sallings‘ Track XMPP clients for both Twitter and Identi.ca (Identi.ca is real time!). Type help to his client and it gives you a whole list of things you can do with it. I’m sure this could easily be expanded further to allow tagging, person tagging, and more.

Twitter and Identi.ca’s announcements supporting linking of replies via the API last week is a very welcome announcement. With just a few more tweaks I think we’re on our way to a much cleaner microblogging environment that is even more searchable, more focused on content, and definitely more organized. For now I’m stuck using ‘@’ and #hashtags.

You can follow me on identi.ca at http://identi.ca/jessestay or FriendFeed at http://friendfeed.com/jessestay.

There’s a new kid in town in the microblogging space, and no it’s not just “another microblogging site”. I talked to Brian Hendrickson, the lead developer behind OpenMicroblogger.org and its accompanying service OpenMicroblogger.com today and he may just have something to scare both Twitter, and Evan Prodromou of Identi.ca in their tracks. What’s amazing about it all is Brian has actually taken the OpenMicroBlogging protocol that Evan established and implemented the protocol in Brian’s own, non-laconica-based implementation of the protocol that would communicate with any other OpenMicroblogging protocol supported site, similar to the way I mentioned on LouisGray earlier. Yes, OpenMicroblogger.com and the accompanying open source software it is based on will talk to Identi.ca, and on a completely different code base. That means you can follow anyone on Identi.ca within the OpenMicroblogger.com service and vice-versa, and they were written from the ground up by two entirely different developers!

What’s even more amazing about this new platform is that while not a Wordpress implementation, Brian seems to have made the platform almost entirely compatible with the Wordpress plugin and theme API. So, basically, if you are a Wordpress developer, you can write your own extensions to the code, implement your own versions of the code, and write your own themes, all in the same way you do on Wordpress. Brian wrote the code from the ground up using a framework he built and calls “dbscript”, and it contains no Wordpress code whatsoever. He felt Wordpress was too bulky to handle a full Microblogging platform (do I smell a potential acquisition by Automattic?). In fact, adding in integration with the OpenMicroBlogging Protocol was as simple as just adding a simple PHP plugin to his dbscript implementaion. The look and feel of OpenMicroblogger.com, his own implementation of the codebase, is all just an implementation of the Wordpress Prologue theme that my friend Joseph Scott at Automattic wrote.

Brian tells me that while Laconi.ca’s codebase is very good technology (he had very good things to say about Identi.ca, Evan, and the Laconi.ca codebase, especially when compared to Twitter), the technology underneath OpenMicroblogger and DBScript is even stronger and more scalable. According to him, “dbscript is an advanced ‘Restful’ framework with sophisticated features that are not found in the Wordpress code base, it shares features with Ruby on Rails (ruby) and Django (python) — things like MVC, ActiveRecord, Routes, Content-Negotiation”. Because the underlying code is Restful, an API is almost inheritently provided for other developers to interact with your implementation of the code-base and write their own applications for it.

OpenMicroblogger and DBScript are based on an open source MIT license similar to the license Ruby is under. Brian says it took him just 8 weeks to write this advanced implementation, with other client projects going on at the same time and 2 kids, which shows how simple it is to implement the Openmicroblogging Protocol. It also shows his devotion to the work.

OpenMicroblogger.com, the service that shows off his code, has some really nice features (also available in the code) such as sharing links and pictures with friends - definitely a little more advanced than Identi.ca in that manner. He fully supports the OpenID standard (he actually wrote his own OpenID host using his framework!), and is very big on OAuth and other standards and open protocols so you can expect to see much more around that with the site.

This one simple and amazing example goes to show that we have only hit the tip of the iceberg here on microblogging technology. Now that a Protocol has been established, you will see more and more sites and developers write their own extensions of the protocol to implement their own creative microblogging solutions and layers. This very creative and innovative solution could just be a more advanced option than Laconi.ca to consider for Microbranded solutions in the future. Brian has taken “viral coding” to heart.

You can download the code, try out, learn more and help out the OpenMicroblogger.org project over at http://openmicroblogger.org. I’ve created an account at http://openmicroblogger.com/?jessestay, and you can actually just go there, follow me, and follow my OpenMicroBlogger.com updates right on Identi.ca! Or, you can go over and create an account for yourself.

UPDATE: Brian corrected me about it being more scalable than Laconi.ca (see the comments below) - according to him, “Actually Laconi.ca is the more robust code and is more scalable. dbscript is a meta-object framework and runs some extra queries to “learn” about the db schema — it is currently not very optimized for performance, but is geared towards being programmer-friendly.”

Yesterday I guest-posted on LouisGray.com about how the technology behind Identi.ca, Laconi.ca, could pose as the launching platform to brand many smaller microblogging services. Today I’d like to share one more power of the service - its working API. Identi.ca/Laconi.ca seem to have introduced a new ideology to Web 2.0 with this code, viral software.

Now, when I mention “viral software”, I’m not necessarily mentioning software that can make things viral. I’m instead meaning software in which the underlying code itself is viral. This could change the face of the way developers write code in the future, and open source is only part of it.

Today I noticed (through Steve Gillmor on identi.ca) another new interesting thing that I knew was coming - Brad Williams (@williamsba) wrote a bridge that essentially allows you to post on identi.ca and have it automatically post to Twitter, prepended by “identi.ca:”. Interestingly enough, “Hippy Steve” (@exador23) pointed out now one of the top trends on Twitter as of today, according to http://search.twitter.com is “identi”. Now, many of the posts you see on Twitter are going to become posts prepended by “identi.ca:”, and many more are going to feel pressured to join identi.ca where they are seeing all their other friends post from. I guess you could consider it competitive micro-advertising, created and distributed on purpose by the users themselves (as Charlene and Josh would put it, we’re seeing a “Groundswell“).

It should be noted that you can remove the “Identi.ca:” from being prepended, but as long as you’re on identi.ca and want those on Twitter to know you’re posting from there and not Twitter, why remove it? You are posting from the competing team, after all. Would anyone want to pretend they’re not posting from Twitter? I’d like to know where my friends are posting from.

Now, onto the viral part. Why did Brad Williams implement this bridge? I’m sure there are preferential issues of trying to get his network onto identi.ca, but the fact of the matter is, from a development standpoint these applications like Brad William’s bridge are simply easier to write for Identi.ca. The lack of limits and plan to keep off those limits on Identi.ca are just one more thing that make the software behind Identi.ca viral. Developers want to develop for Identi.ca. With an API that also supports Twitter (I mean literally, it is simply a change in the hostname for your Twitter code), developing for Identi.ca is just too easy! Again, developers jumping ship could very well mean the demise for Twitter.

I can only hope that developers of the future learn from this experience - in a social era such as today, even your software has to remain viral and easily shareable and distributable. Laconi.ca is the prime example of this - completely open source, based on open protocols, and your software should be able to talk to other instances of itself in some way, preferably using standard protocols. In addition to that, a completely open API is a must - the minute you start closing your API you begin to lose your code’s virality. Brad William’s bridge is only the start of apps that make the transition to Identi.ca much easier. I imagine you’ll see many more of these things in the coming days and weeks.

Looking to learn more on how to make the jump to identi.ca? Check out my friend, Marina Martin’s site, ohidentica.com for some great howtos and tips all in one place. You can find me at http://identi.ca/jessestay.

O’Reilly just published a great interview with me on their FYI blog. If you want to learn why my book, FBML Essentials is important to you as a Facebook developer or business looking to develop Facebook applications, you should check it out. At the end, Mary Rotman announced a competition that could get you a free copy of my book, straight from O’Reilly.

Here’s the deal: regardless of whether you’re a Facebook developer or not, all you need is an idea. Let’s consider this the pre-cursor to getting your fbFund money — I’ll show you how to get started making the app, fbFund will fund the way. Simply go to O’Reilly’s FYI post and enter in the comments the application you would build (or are building) and how it’s different from the rest of the hundreds of Facebook applications out there. The best one or two ideas get a free copy of FBML Essentials - bring it to the next Social Media conference that I’m at and I’ll even sign it for you! How cool is that???