Open Source

As open source usage has grown into the mainstream, have users started to contribute less time and money to open source projects, thereby putting the future of the project at risk? One CEO of a leading open source based company thinks so.

Open Source loses it cachet
Today vendors are adding “cloud” into the description of their company or product for two reasons. First, in the hopes of riding the hype around cloud computing. Second, in order to shape the definition of what a cloud company or product is.

The above held true for “open source” five years ago.

Since then, open source has become much better understood as a development, distribution, pricing and licensing model by IT decision makers today. As a result, as The 451 Group’s Matt Aslett explains, the term “open source” holds less value as a differentiator for vendors. Aslett writes:

“…but these are among the highest profile open source-related vendors, so the fact that half of them have dropped open source as an identifying differentiator in the last 12 months (and another two long before that) is not insignificant.”

User contributions on a decline?
Brian Gentile, CEO of JasperSoft, an open source business intelligence vendor, agrees with Aslett’s conclusion that the term “open source” has lost its differentiating ability as open source is a mainstream option for many companies.

As open source has become mainstream, Gentile writes that he is seeing a decline in user contribution of time and money to open source communities. Gentile defines user contributions as follows:

“Open source communities thrive based on the community members donating either their time and/or money. Donating money typically comes in the form of buying or subscribing to the commercial versions of the open source products. Donating time can come in a wide variety of forms, including providing technical support for one another in forums, reviewing and commenting on projects, helping to QA a release candidate, assisting in localization efforts, and of course contributing code improvements (features, bug fixes and the like).”

Results from the 2010 Eclipse Survey support Gentile’s claims about user contributions of time declining.

In 2010, 41 percent of respondents, up from 27 percent in 2009, claimed they use open source software without contributing to the project.

Part of the decline in contribution is surely linked to corporate policies. The Eclipse survey found that 35 percent of respondents in 2010, down from 48 percent in 2009, claimed their employer’s corporate policies allowed employees to contribute to open source projects.

Open source users and customers are different
Is user contribution of money to an open source project also on a decline as Gentile worries?

James Dixon, CTO and founder of Pentaho, also an open source business intelligence vendor, disagrees with Gentile’s notion of users contributing money to a project.

Dixon believes that attempting to sell an enterprise version of software and services to community members is a mistake, one which misses the distinction between users and customers.

“As a commercial open source (COSS) company you can provide tools for your community members to persuade their employers to become customers, and you can explain how this benefits both companies involved and the community. For most COSS companies is it impossible to monetize the community directly, and therefore ridiculous to try.”

Users can contribute time, customers can contribute money
It’s important to separate, as Dixon does, the expectations on users versus customers. For enterprise software, users seldom have the budget authority to become paying customers. Users can encourage IT decision makers to become customers.

Gentile is correct in stating that users of an open source project, especially an early stage project, contribute their time to a project.

As the project becomes widely adopted by users, companies decide to adopt the resulting product from the open source project. These companies contribute money to the vendor, who in turn uses the funds to further enhance the product and the open source project.

A decline in user contributions of time is not necessarily an issue. Nor should it be concerning that community users aren’t contributing money to a project, for the simple reason that they don’t have the budget authority to do so within an enterprise.

Over time, user contribution declines, but the project is sustained by the funds made available to the project through corporate purchasers of the product. In a sense, as projects mature, user contribution of time is inversely proportional to customer contribution of money.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

NoSQL is still not well understood, as a term or a database market category, by enterprise IT decision makers. However, one NoSQL vendor, 10gen, creators of open source MongoDB, appears to be growing into enterprise accounts and distancing themselves from competitors. If you’re considering, or curious about, NoSQL databases, spend some time looking at MongoDB.

Understanding not only SQL, aka NoSQL
While the term NoSQL suggests a product category that is anti-SQL or anti-relational databases, the term has evolved to mean “not only SQL”.

According to, there are over 122 NoSQL database products to date. These products differ from traditional relational databases as they don’t rely on a relational model, are often schema free and support eventually consistent, not ACID, transactions.

While companies needing to manage terabytes of data across commodity servers, such as Facebook, FourSquare or Shutterfly have been early adopters of NoSQL databases, traditional enterprises such as Disney and Intuit are joining the NoSQL customer list.

Max Schireson, president of 10Gen, asserts that relational databases are here to stay and have an important role to play in tomorrow’s enterprise.

Schireson sees NoSQL and relational databases both being used within a given enterprise, albeit for different applications.

If this positioning sounds familiar, recall that MySQL attempted to paint a picture of co-habitation with enterprise database vendors.

If an application is processing sales orders and needs absolute guaranteed transactions, a relational database supporting ACID transactions is a must. If an application is processing millions of events, such as click streams, in order to better optimize an online sales catalog, and losing a few of those events is less critical than being able to scale the application and data across commodity servers, then a NoSQL database could be a perfect fit.

MongoDB distances itself from NoSQL alternatives
While NoSQL databases such as Cassandra, originally developed and used by Facebook, or CouchDB get a lot of media attention, MongoDB appears to be the product to catch in this hot market.

Worldwide Google searches for various NoSQL product names shows the marked increase in MongoDB and Mongo searches since January 2011. Google searches for MongoDB and Mongo exceeded searches for CouchDB, Couchbase, Membase, Cassandra, and HBase combined.

According to, jobs seeking MongoDB or Mongo skills have outpaced other leading NoSQL products. MongoDB and Mongo now represent the most sought after NoSQL skills amongst companies hiring on

Recently announced platform as a service offerings from Red Hat and VMware featured MongoDB at the data services layer of their respective offerings.

Schireson shared some stats on 10Gen’s commercial business growth into the enterprise with MongoDB.

Six months ago the majority of 10Gen customers were startups; today the majority are traditional enterprise customers. In fact, 10Gen counts five Fortune 100 companies amongst its over 200 paying customers.

With over 100,000 downloads per month and developer attendance to MongoDB conferences increasing 400 percent to nearly 2,000 across San Francisco, New York and Beijing, MongoDB traction continues to increase.

Schireson explained that many enterprises have developers interested in MongoDB, as the above download and conference attendance data backs up. However, enterprises are waiting for their peers to go first into the world of NoSQL.

Schireson revealed that securing Disney as a public MongoDB reference has led to increased enterprise interest in 10gen from MongoDB users.

MSQL poster child Craigslist adopts MongoDB
Another recent coup for 10Gen was winning Craigslist as a customer of MongoDB.

Craigslist’s Jeremy Zawodny, author of the popular High Performance MySQL book, recently spoke about Craigslist adopting MongoDB to handle Craigslist’s multi-billion document deployment. Zawodny explains Craigslist’s evolution from being a MySQL everywhere shop to selecting the appropriate database technology based on varying data and performance needs.

When Zawodny, a MySQL performance guru, gets behind MongoDB, it’s time for enterprises interested in NoSQL to consider MongoDB.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

An ex-Google employee recently expressed concerns about the antiquity of Google’s software infrastructure. This is the same software infrastructure underpinning Google’s App Engine. Learn more before your enterprise considers Google App Engine.

Engineer claims Google’s software infrastructure is obsolete
In a post explaining why he’s leaving Google, former Google Wave engineer Dhanji R. Prasanna wrote:

Here is something you’ve may have heard but never quite believed before: Google’s vaunted scalable software infrastructure is obsolete. Don’t get me wrong, their hardware and datacenters are the best in the world, and as far as I know, nobody is close to matching it. But the software stack on top of it is 10 years old, aging and designed for building search engines and crawlers. And it is well and truly obsolete.

Protocol Buffers, BigTable and MapReduce are ancient, creaking dinosaurs compared to MessagePack, JSON, and Hadoop. And new projects like GWT, Closure and MegaStore are sluggish, overengineered Leviathans compared to fast, elegant tools like jQuery and mongoDB. Designed by engineers in a vacuum, rather than by developers who have need of tools.

Prasanna argues that Google’s software infrastructure hasn’t kept up with alternatives developed in an open community forum.

Don’t take Prasanna’s statements as those of a disgruntled ex-employee. He writes that working for Google was the “best job I’ve ever had, by a long way”. Additionally, Prasanna had built up serious technical credibility, both within and outside of Google, especially in the Java arena.

As interesting as Prasanna comments may be, Google software infrastructure has little impact on your enterprise, right? Correct, unless you’re considering Google App Engine.

Google’s software infrastructure bleeds through Google App Engine
Google isn’t going to open source its back end software infrastructure. However, as the Register’s Cade Metz writes, Google’s software infrastructure is surfaced for enterprise usage through Google’s App Engine.

Google App Engine product manager Sean Lynch, who has since left the company, explains how Google exposes their internal software infrastructure to 3rd party developers and enterprises. Lynch states:

We decided we could take a lot of this infrastructure and expose it in a way that would let third-party developers use it – leverage the knowledge and techniques we have built up – to basically simplify the entire process of building their own web apps: building them, managing them once they’re up there, and scaling them once they take off.

Make no mistake, Google App Engine is a success with developers, with over 100,000 developers accessing the online console each month and serving up 1.5 billion page views a day according to Metz’s story. However, keep in mind the difference between success with developers versus success with enterprises.

Lynch stated that Google App Engine is a long term business focused on the enterprise space. Later this year, Google App Engine expects to exit of a three-year beta period and introduce enterprise class service level agreements.

Google App Engine started as a way to expose Google vaunted, to use Prasanna’s description, software infrastructure to third party developers. But it appears that the market has moved faster than Google’s internal users demanded.

Enterprises seek vendors whose core business is linked to the software platform they’re selling
I would propose that part of this gap between Google and outside technologies is driven by the fact that offering a cloud platform as a service is not core to Google’s business. This is why I’ve argued that commercial software vendors have little to fear from vendors that produce software primarily for their own use and then opt to secondarily open source the code. Unless and until the open sourced code is picked up by one or more vendors whose core business is tied to the project, enterprises will shy away from adoption.

Consider where Hadoop, first developed and open source by Yahoo!, would be if not for Cloudera and other vendors whose core business is linked to the enterprise success of Hadoop.

In the case of Google App Engine, a key question to ask is how your enterprise needs will be prioritized against the needs of internal Google developers.

While both user groups would share a set of feature requests, there are undoubtedly features that enterprises will seek that Google developers will not need. With both user groups vying for the next feature on their wish-list to be completed, will Google address the needs of its internal developers or third party enterprise? Keep in mind that revenue from projects that internal developers are working on will far outweigh revenue from third party enterprises through Google App Engine for the foreseeable future.

According to Prasanna, developers and enterprises can get more innovative, state of the art and high performance software infrastructure from open source projects that have replicated some of Google’s best ideas, like Hadoop or mongoDB, than by using Google’s software infrastructure itself.

Combining individual best of breed software building blocks into a cloud platform as a service environment that offers the functionality of Google App Engine, requires enterprises to do a lot more work than simply using Google App Engine.

Another alternative would be to consider a vendor whose business is tied to the success, or failure, of the cloud platform as a service offering. For instance,, VMware, Red Hat, Microsoft, and IBM, to name but a few vendors, offer environments designed and built for third party enterprise use.

Keep these considerations in mind while evaluating Google App Engine, or any cloud platform as a service offering for enterprise use.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

Oracle’s recently announced a proposal to move the open source Hudson project to the Eclipse Foundation. Should your company’s stance on Jenkins or Hudson change as a result? Short answer, no. The more interesting question is what this contribution means for the Eclipse Foundation.

Eclipse contribution won’t mend the Hudson & Jenkins split
In explaining Oracle’s proposal, Ted Farrell, Chief Architect and Vice President, Tools and Middleware at Oracle, writes:

…I can’t speak for the Jenkins folks, but one of the good things about Hudson moving to Eclipse is that anyone can participate. When the fork happened, I think it came down to a difference of opinion about how to run an open source project. Oracle and Sonatype wanted more of an enterprise focus, and CloudBees wanted more of a grass-roots environment which is how Hudson came to be. I think both are valid opinions.

So when we started talking about this move to Eclipse, we initially focused on talking to people whose views were more in line with our Enterprise focus. Now that the proposal is public, we welcome anyone to join the conversation over the next 2 months while we finalize the submission and get it accepted.

Farrell makes several points that appear counter to the public record.

First, unlike Oracle, CloudBees relies on Jenkins to power a commercial product aimed at enterprises. To claim that CloudBees has anything less than an “enterprise focus” is curious.

Second, when a community around any open source product up and moves to another location, under a different project name, that’s not a fork – that’s a rebranding. Jenkins community member Andrew Bayer told InfoWorld’s Paul Krill:

The Jenkins organization on GitHub now has almost 500 repositories, the majority of those plug-ins, and almost 100 public members, while Hudson only has its core repository available and only four public members. Of the 25 most commonly installed plug-ins from before the split, 21 of them have moved primary development to focus on Jenkins, with the remaining four not having any changes during that time. In fact, 40 new plug-ins have been added to Jenkins since the split, while only one has been added to Hudson. The development community has definitely made its choice heard.

The lack of community response on the Hudson proposal mailing list at Eclipse is not a very good start for the project. Two individuals that have commented suggest they support the proposal if it will unify the Hudson and Jenkins camps. However, there’ no indication of a Hudson and Jenkins unification occurring as a result of the Eclipse contribution proposal.

Eclipse at risk of becoming a graveyard for abandoned OSS projects
Like most, I’m a big fan of the Eclipse Foundation, not simply because Ian and Mike are Canadians!

However, I fear that Eclipse is at risk of becoming a home for projects whose owners are looking to gracefully reduce their investments while gaining some open source kudos along the way.

Rewind to November 2009 when Oracle and SpringSource jointly announced the Gemini project proposal. Gemini was based on SpringSource’s DM Server technology. Two short months later SpringSource announced the Virgo project proposal to contribute SpringSource’s dm Server to Eclipse. Although SpringSource had been a big proponent of OSGi, OSGi and dm Server became less of a priority for SpringSource after it was acquired by VMware.

SpringSource tried to play up the potential for increased community contributions to the Gemini project.

However, VMware/SpringSource killed off their dm Server product as a result of contributing the project to the Eclipse Foundation. The lack of a product and revenue linked to the Eclipse project should have been a warning sign for the Eclipse Foundation.

A year and a half later, while OSGi support is offered by WebSphere, GlassFish and JBoss, and continues to gain developer attention, the Eclipse Gemini project is stuck in neutral.

Does Oracle, or more importantly, the Eclipse Foundation, truly expect a better fate for Hudson?

Oracle doesn’t have a viable business associated with Hudson. This makes any future investment decisions regarding the project at Eclipse tenuous at best. Cue the graceful exit music.

While I agree that, “if you’re going to kill it, open source it!“, I simply don’t think that the Eclipse Foundation needs to be, or should want to be, the destination of choice for these types of projects.

I hope I’m wrong about the fate of Hudson at the Eclipse Foundation. The Eclipse Foundation is too important to open source projects to become, or even just be viewed as, anything but a leading destination of choice for new and exciting projects.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

A recently released survey of 2,760 mobile application developers reveals challenges for Google, Microsoft and RIM around fragmentation and access to developer time and mindshare.

The survey was conducted in early April 2011 by research firm IDC, and Appcelerator, a mobile development platform provider for building cross-mobile platform applications using HTML, CSS, JavaScript, PHP, Python and Ruby. Appcelerator claims 1.5 million developers and over 20,000 applications built with its open source products.

Not surprisingly, Apple and Android phones and tablets occupy the top four spots in terms of developer interest in developing for a certain platform. There’s over a 40 percent gap between the two leaders and everyone else, including RIM, Microsoft and HP’s respective mobile platforms.

Android’s challenges with fragmentation
The survey gets interesting when developers discuss their concerns with Android. Fragmentation is overwhelming the number one concern.

A feature/function comparison versus Apple’s iOS or ability to make more money from Apple’s ecosystem are at the bottom of the Android concerns list.

IDC and Appcelerator also point out that there appears to be significant gap between interest in Android as a tablet OS and tablets that support Android.

On the software side, 71% respondents are “very interested” in the Android OS, but on the hardware side, only 52% are very interested in developing applications for the Samsung Galaxy tab. This drops to 44% for Motorola Xoom, the first Android tablet with Android’s Honeycomb OS.

This is somewhat surprising considering the relatively strong hardware specifications, especially compared to the likes of Apple’s iPad 2, that Android tablets offer. However, fragmentation concerns may be a root cause to the lack of interest in having to test with and support the various Android tablet offerings.

One can see why Google is working hard to reduce fragmentation, even if it allows outsiders call Google’s open source credentials into question.

RIM and Microsoft’s race for relevance
When asked if any other platform can catch up to Apple or Google, 62 percent of respondents said “no”.

Digging deeper, the respondents are more interested in the Microsoft & Nokia partnership versus announcements from RIM or HP surrounding their respective mobile platforms. Respondents felt that the Microsoft and Nokia partnership could position Microsoft as a more serious competitor to Apple and Google.

However, even amongst this group, when asked what poses the biggest risk to the success of Microsoft’s mobile platform, 46 percent answered, “not enough time”. The only higher ranking risk was a perception that Google and Apple are just too far ahead.

What’s troubling is that Appcelerator helps developers build native, cross-device mobile applications from a single code base for iOS, Android, and Blackberry.

These developers can’t find the time to target anything other than iOS and Android, even with a tool that addresses multi-platform support from a single code base.

These developers are saying that the marginal cost of tailoring the single code base application for RIM or Microsoft platforms is outweighed by the value of delivering the next feature for iOS and Android users of their application.

I would have expected these responses from developers tasked with building for multiple mobile platforms without the benefit of a cross-device framework or tool like Appcenerator offers.

RIM, Microsoft and others hoping to catch Apple and Google, need to dig deeper into these results and determine what can be done to keep developers interested in building for their mobile platforms.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

Devops, a term coined to describe the expanding reach of developers into areas typically considered operations tasks, is still viewed as a trend impacting early adopter enterprises – but for how long? What can you do to prepare what should you look for in technology that enables the devops model?

The developer land grab that is devops
The desire to release new functionality faster to end users is high on every developer’s wish list. However, most enterprises have multiple layers of processes, assigned to separate roles, which often increase the time between a new feature being developed and made available to users. However, most IT managers would agree that these processes and separation of roles were instituted to increase the quality and uptime of IT environments, and ultimately the quality of the end user experience.

The growing access to automated, self service, provisioning of IT resources and environments is enabling developers to flatten the roles, if not processes, between a developer and the end user.

RedMonk’s Michael Cote suggests that devops can be viewed as a land grab by developers. Cote writes, “after ejecting every function except writing code, development teams have been bringing those roles back to the core team, starting with QA, then product management, and now operations.”

Not surprisingly, devops is taking hold primarily in startups or smaller companies where the separation of developer versus operations roles is ill-defined by necessity.

The changing role of operations in a devops world
In larger enterprises with established separation of roles between developers and operations teams, the devops term may in fact be counter productive. It can suggest that as developers undertake tasks previously owned by the operations team, operations staff become less critical to the IT organization.

In fact, the reality underlying devops is far from that mistaken belief. Cote describes the changing role of operations staff in a cloud-driven devops world:

Rather, it means that as with QA and product management, their role moves from “keeping the lights green” to “delivering good, productive experiences.” Operations becomes one of the product owners, not just the “monkeys” who hook up wires to servers and increase disk-space.

The451 Group’s Jay Lyman shares a similar view in his research on devops, concluding:

However, in the larger picture and in the long run, particularly at greater scale, there is undoubtedly need for system administrators. One of the bottom line findings of my research on devops is that the trend is very much about a dramatically changed purpose and role for system administrators, who are typically freed up of mundane OS maintenance and other tasks, but who must also embrace openness and transparency in their operations and scripts, which can be very foreign.

Far from developers replacing operations staff, and thereby accepting some of the manual tasks required to keep an environment up and running, new cloud technology removes the need for these manual, and at times mundane, tasks in the first place. As these tasks are removed, operations teams are able to better contribute to the value that their business and end users perceive to be coming from IT.

Transitioning towards a devops model
Much of the transition required by the devops model involves changes to organizational design, processes and a revised definition of roles. These types of transitions can be lengthy in duration and often face resistance initially.

It is for exactly this reason that vendors must offer both an evolutionary and revolutionary option in their cloud and PaaS offerings targeted at enterprises.

An evolutionary approach is required to help IT organizations gain value while they transition to tomorrow’s more responsive and productive IT organization. Without this evolutionary step, the desire to protect one’s sphere of influence in the overall IT process will encourage IT staff to resist change before they can see the benefit of a cloud-enabled devops model.

A revolutionary approach also needs to be delivered in the same cloud-focused tool or product. This choice enables enterprises to shift gears between evolution and revolution in their IT processes without having to acquire separate products with separate skills requirements. More importantly, this choice allows enterprises to shift between evolution and revolution in their IT processes at their own rate and pace.

VMware’s open source-based Cloud Foundry beta and IBM’s Workload Deployer are two PaaS offering that attack the devops opportunity from two ends of the spectrum.

VMware’s beta offering appears targeted at enterprises ready for revolution, with a developer in control of the overall development to deployment process. It’s too early to tell if this is by design, or simply didn’t make it into the developer targeted marketing surrounding the beta. Knowing VMware’s long history with enterprises, one would expect VMware to address the spectrum of stakeholders whose roles are impacted by cloud and PaaS in a devops model.

IBM’s offering assumes that enterprises want to select between both evolution and revolution in their IT processes on a project by project basis while. This choice enables IT organizations to secure buy in from IT employees after proving out the benefits of more closely aligned developer and operations functions in a given project.

Preparing for a devops future
Like any major change in processes or role definition, IT decision makers need to allocate sufficient time for the shift to occur.

Successful transitions will most likely occur if there are proof points, relevant not only to the business, but to developers and operations staff, from a handful of smaller projects. Selecting projects, developers and operations staff that would be best suited for a new way of doing things would be a good fist step.

Additionally, determine the degree to which your IT organization can accept the revolutionary changes to roles and processes as codified by the cloud and PaaS tools you consider. Select your cloud and PaaS tools based on your organization’s unique needs.

Whatever you do, starting to think about devops models sooner rather than later, is the right approach for building tomorrow’s IT department.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

A high profile VC and a well-known mobile application developer were recently involved in a debate about whether to build for Android or Apple mobile platforms. The answer it turns out is, it depends, or both, or simply build for the mobile browser.

App developers and companies have different goals, so why follow the same advice
Well respected VC, Fred Wilson, principal of Union Square Ventures, has previously suggested that developers interested in the largest user base should invest as much, if not more, in developing for Android as they do for iOS. Wilson justifies his recommendation by looking back at the desktop operating system market. Wilson writes, “I believe the mobile OS market will play out very similarly to Windows and Macintosh, with Android in the role of Windows.”

Countering Wilson’s advice is Marco Arment, founder of Instapaper and former lead developer of Tumblr. Marco suggests developers need to keep a closer eye on development economics, degree of fragmentation, payment integration, and the willingness of users to pay for applications or extensions on a given mobile OS platform.

Marco’s advice is likely to resonate with individual developers hoping to directly monetize their mobile application either through selling the application or through in-application purchases. Over time however, one shouldn’t bet against Android closing the gap versus Apple along the lines of development economics, payment ease of use and fragmentation.

It remains to be seen whether Apple’s platform can continue to generate higher application and in-application purchase revenue for developers even while Android boasts the #1 mobile OS by unit share. Today, the App Store revenue gap between Apple and all other mobile platforms is striking.

On the other hand, a company that sells goods or services which are exposed through the mobile application, but does not monetize the application itself, needs to pay more attention to Wilson’s advice. If the vast majority of a bank or retailer’s prospective users are going to use an Android device, the company had better offer a compelling user experience on that platform.

But why choose between developing for Android or Apple?

Build mobile web browser applications
It’s somewhat amazing to watch companies that don’t rely on directly monetizing their mobile application invest in native mobile applications for iOS or Android. In a rush to be the first to market, companies optimized for a device rather than following the cross-platform and cross-browser web application strategy they’ve used for the better part of a decade.

Not surprisingly, this will change thanks to HTML 5, CSS 3 and JavaScript.

For instance, if TweetDeck, which is best known for its thick-desktop client, can see the light and deliver the same user experience in a web-browser across desktop and mobile devices, chances are your company’s web application can evolve into a mobile web browser application without paying the cost of device-specific implementations.

The key element of TweetDeck’s announcement is that “TweetDeck Web, however, is a standalone web site and requires no downloads, no App Stores and is not limited to any one brand of web browser.”

No App Stores is a win for the browser
The “no App Stores” angle obviously has its pros and cons. However, unlike individual developers, companies that aren’t monetizing the mobile app itself don’t need to rely on an App Store to attract users. They already have users and other processes to attract new users. Their users simply want to interact with these companies through mobile devices. Putting the company’s web application into an App Store adds extra hurdles for users and for the company when it comes to fixing defects or updating the application with new features.

If users begin to rely more on App Stores and less on the Internet itself for finding new vendors of goods or services, being in the App Store of choice will become as important as being listed in Google’s web index. But we’re years away from this scenario becoming reality, if ever. In the short to medium term, established companies can well address new and existing customers through a mobile web browser application.

It’s strange that Google hasn’t recognized the mobile browser-based application opportunity and is instead attempting to replicate Apple’s App Store strategy. The browser undermines the value of the underlying OS.  And since Google doesn’t much care to profit from the underlying OS or the device, unlike Apple, they should be encouraging companies to build mobile web applications, not device-native applications. Google should be indexing and promoting these mobile web browser-based applications.

Consider cross-device frameworks as a step towards standard browser applications
For individual developers and companies that need to be an App Store, or want to access more of the device native capabilities, such as the camera or GPS, then evaluate the various cross-device frameworks previously covered on Open Sources. For instance, PhoneGap already has an impressive list of cross-device native feature support. Using a framework such as PhoneGap, and their build service could make it easier, faster and cheaper to build applications for Android and iOS, instead of having to decide which platform to prioritize.

Over time, standards will emerge to access core mobile device capabilities, such as the camera or contact list, in a cross-device fashion. Whether this occurs through defacto standards around a framework such as PhoneGap, or a formal standards body efforts is unclear. Maybe Google will smarten up and realize they have more to gain by spearheading this initiative than trying to play Apple’s App Store game.

If the past decade has taught us anything, it’s that the browser is the application runtime that matters most. Build for the browser.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

« Previous PageNext Page »