The mobile-computing world is increasingly a two-horse race between Google and Apple, with Apple clearly in the lead but Google Android making up ground quickly. Microsoft and Symbian are also still in the game, but the ultimate winner will be the one that best appeals to consumers or developers.
Or both.
Sexy? Yes. But what about the developers?
This struck home while reading Mark Sigal's analysis of the "inevitability" of Google Android. On his way to dismantling the idea that Google's victory is assured, Sigal stumbles into apparently divergent interest groups:
[U]nlike the PC, where "good enough" was the bar required to seize the market,...for most consumers, their mobile device of choice is a lifestyle decision, a personal, ever-present extension of themselves that is resident in a way that never existed before with the PC--a value proposition that Apple has completely run with on iPhone (and iPod before that).
Fundamentally, though, mobile is a platform play, a game that is largely won by securing the hearts and minds of developers, and for them, the expectation bar is now set pretty high, owing to the success of iPhone across so many domains....
If you're Google (or Microsoft or Symbian), then, who do you target? Developers or consumers?
It's a real question, as while both parties' interests ultimately converge (consumers want developers to make great applications so that those same consumers can pay the developers lots of money), the short-term interests of consumers (sexy product) and developers (ease and richness of development platform) don't necessarily go together.
Motorola RAZR? Sexy product, lame development platform. Windows Mobile? Arguably a solid development platform...with almost zero sex appeal for consumers.
This is why John Carroll is probably right to argue that Microsoft should reinvigorate its mobile strategy with an emphasis on .Net as a powerful way for developers to write powerful mobile applications, it's not going to be enough. Microsoft can port all the business applications it wants for Windows Mobile. It won't matter.
Consumers don't buy business applications. Not until after they've chosen a phone that meets their personal needs, first.
Yes, enterprises do try to dictate corporate standards with Blackberrys and dull Dell PCs heading the list. But in the fast-changing mobile market, you can't hope that consumers will be forced to use your software. You want them to want to do so.
This is why I believe Google has a good chance of taking a serious bite out of Apple, and Symbian and Microsoft do not. Symbian is too difficult an application development platform, as Gartner notes, and Microsoft...is boring.
Not that it needs to be. XBox certainly isn't, and actually helped Microsoft surpass Apple in a recent consumer survey focused on product innovation.
But not in mobile, or even in computers. Apple understands how to create wicked cool products that consumers want, which is why its Mac sales are projected to grow by 26 percent in 2010, right through the recession, and why its iPhone continues to thrive.
But Apple's Achilles heel could well be developers, which are reportedly tiring of Apple's apparently arbitrary application approval and updating process. If Google can continue to help handset manufacturers to achieve the "Wow factor," while simultaneously creating a more open, robust development platform, it just might be able to beat Apple at the game it started.
In other words, the winning mobile vendor will be the one that marries sex appeal for consumers with platform appeal for developers. Google is on course to deliver, but it probably needs to win big with consumers before it makes waves with developers.
President Obama is gathering 100 leaders from across the U.S. for his jobs summit in Washington on Thursday to brainstorm how to create new jobs.
While the list of invitees is heavy on academics, labor unions, and business, it appears only two people from technology made an early invitation list: Eric Schmidt, CEO of Google, and Jim Whitehurst, CEO of Red Hat.
FedEx. Yes. Nucor. Yes. But no Microsoft. No Oracle. No Salesforce.com. What gives?
Yes, Schmidt is a key advisor to Obama. But his invitation, along with Whitehurst's, could have a lot to do with the fact that Google and Red Hat, unlike many of their peers, are actively hiring.
Red Hat and Google have thrived through the recession, perhaps suggesting that they have a clue as to what it will take to create new jobs in a tough economy, one that has seen 23 straight months of job losses.
Intriguingly, Google's hiring may be crimped more by a desire not to aggregate all of the best and brightest than an inability to do so, as evinced by Google Vice President Bradley Horowitz's comments at Supernova this week.
When I asked Whitehurst on Wednesday what he thought the two companies had in common, he was quick to respond: "open source."
It's an interesting observation. While the two companies use open source in different ways, their business models are actually more similar than different, and both depend on open source.
As I've written, both Google and Red Hat (along with Facebook and other new-school "software" companies) depend upon and help to create abundance--of code, of Web sites, of information--and then make money by filtering that abundance.
It's a model that works, and it's a model that heavily depends upon and contributes to open-source software.
It would be going too far to suggest that open source is the critical component of any successful technology business today, especially as just about every company now includes it in their offerings in some way. Plus, CIOs have discovered other ways to stretch IT budgets and keep their workers on the payroll, as Gartner advises.
But the mentality of open source--more with less, sharing code and expertise--does seem to be a hallmark of successful technology companies, and particularly at Google and Red Hat.
Everyone hates patent trolls (except, perhaps, the patent trolls' mothers). But it's easier to despise patent trolls when you either have a lot of patents, or none. What if your company were awarded a significant patent that could be used to shake down Google and the rest of the industry for corporate benefit.
Or buy food for your family?
Is it your fiduciary duty to exercise that patent? Is it a personal duty? And do you have the legal right to do so?
The first two questions are tricky, but the last one is currently being considered by the U.S. Supreme Court. Consider yourself lucky that you don't have to decide it.
Bilski and business method patents
Recently, the U.S. Supreme Court heard oral arguments in the controversial Bilski case where IBM, typically friendly to open source and innovation, backed the wrong horse. According to The Wall Street Journal's coverage of the arguments, the justices were skeptical--if not contemptuous--of the case put forward by Bilski and the proponents of business method patents.
Chief Justice John Roberts quipped that business method patents are akin to patenting the idea that "I buy low and sell high. That's my patent for maximizing wealth."
Silly when presented in this way. But perhaps silly when presented in just about any way.
Business method patents came into being 20 years ago with the Federal Circuit's State Street decision, the case that spawned Bilski. Two of the best-known technology examples of such patents are Amazon's one-click checkout and Priceline's reverse auction.
In a September blog I took IBM to the woodshed for its stance on Bilski. Big Blue filed an amicus brief (PDF) that I argued was disingenuous at best. IBM argued:
Patent protection has promoted the free sharing of source code...which has fueled the explosive growth of open source software development.
Really?!?
IBM was not alone. Novartis, the big pharmaceutical company, also filed a supporting brief.
The industry's moment of (in)decision
I think that the Bilski case is a divider of wheat from chaff, a moment that forces technology companies to take sides on a critical issue that goes to the heart of innovation in our economy.
On one side, companies such as IBM and Novartis maintain that patents should not be tied to "primitive physical technology" but should also embrace a broader range of modern business activities.
But other companies, including Google and Symantec, took the other side and filed briefs (PDF) with the Supreme Court arguing that expanded business method patents would open them up to infringement lawsuits over the "very mental processes and ideas that are the building blocks of innovation."
What would you do? LogLogic and Sponster examples...
I was reminded of this issue by an announcement today from LogLogic, a log management and security company I wrote about last year as an example of the pervasive use of embedded Linux.
LogLogic was granted a patent in October that appears to be rather sweeping in its scope, covering the collection of logs and the management of the data in those logs.
Imagine if LogLogic went "troll" with this patent....
At a minimum it could be a nuisance to its competitors and at a maximum it could possibly shake down any company that sold a product that relied on log collection (describing hundreds, if not thousands, of products on the market today).
Or how about this one? Sponster has a patent on a system for delivering contextual ads against electronic messages like e-mail, SMS, tweets, etc. Google filed for a similar patent, but over a year after Sponster, and while Sponster's patent was recently granted in October, Google's was denied. (Disclosure: I know and am friends with one of the Sponster executives.)
On the one hand, Sponster could go troll and sue just about everyone on the Web. On the other hand, I know from talking with the executives that they have no desire to do so. The fact that the company has not sued anyone in its six-plus years of existence is a clear indication of this. Sponster wants to build its business around the patent, but Google or Microsoft with their heft can squash that desire.
Should Sponster fight or capitulate? It's easy when you think of patent trolls as trolls that create no real value. But what about when they are real people and real companies like Sponster and LogLogic?
LogLogic makes its choice
LogLogic appears to have made its decision. In a company blog on Wednesday, a LogLogic executive points out the potential harm they see in a Bilski decision by the Supreme Court that would allow broader business patent methods.
LogLogic also (correctly, in my view) argues that the anti-business method lobby of Google et al "represent[s] the true innovative spirit of Silicon Valley where entrepreneurs are rewarded for risk taking and embrace the thinking of Austrian economist Joseph Schumpeter and creative destruction."
LogLogic decided to take a defensive posture with this sweeping patent rather than go troll. Who knows what Sponster will do, or should do. Presumably it worked just as hard on its technology as Google: shouldn't it get paid?
More broadly, do you agree with IBM that business methods should be upheld, or with Google that they should be crushed? What would your company decide to do? Where do you stand?
With open-source software businesses, you have two options. Actually, three, but the third belongs to Red Hat, and it applies to roughly no one else.
The first option is to sell support for open-source software. This option is generally advocated by those who have never grown a business beyond $10 million. It's a terrible model unless your only aspiration in life is to run a services company.
Hence, the support model might be good for Accenture or systems integrator, if they want to take on the burden of support, but it's a poor model for Red Hat, MindTouch, Microsoft, or other software company.
The second option is to contribute heavily to open source but not build your revenue model around monetizing that software directly. This is what the New York Times points to in its Sunday expose of allegedly fizzling open-source business models.
Open source can drive adoption like little else. It's not, however, necessarily a great driver of revenue. For that, you need to be selling something beyond the source code, and that "something" is often going to be proprietary, be it hardware, software, or a service.
Proprietary search revenue funds a lot of open-source development at Google.
That's the way successful companies are run: they take ownership of what they ship. They are influenced by but not controlled by the mystical whims of The Community.
Even Red Hat, which piggybacks on a lot of Linux kernel development, increasingly includes more home-grown software in its distribution and takes great pains to certify its Red Hat Enterprise Linux will work in the most demanding environments before putting its brand on the label.
Some, including me, have wrongly concluded that Red Hat's business model would apply to other product markets beyond the operating system. It doesn't. It only applies where the moving parts in the product are complex, multitudinous, and frequently changing.
For everything else, there's Option 1 (if you want a business that doesn't scale well or possibly at all) or Option 2 (which is really no different from the old proprietary model except that it effectively uses open-source complements to lower engineering costs and possibly sales/marketing costs).
Even Option 2 won't work if you under-invest in marketing and development, as Symbian is learning to its hurt. It turns out that there is no free lunch, even in the land of free software. It always takes work. And money. Lots of both, actually.
For those who have fret about Microsoft fighting against open source, I have news for you: Microsoft's impact on open source may be worse as a friend than as an enemy.
Now with MySQL inside! Yes, we can.
(Credit: Microsoft)Over the past few years, Microsoft has steadily warmed to open source, to the point that it now hosts its own open-source code repository and has seen its Microsoft Public License used more often than venerable licenses like the Mozilla Public License or the Eclipse Public License, according to new data released by Black Duck Software.
The open-source world should be worried.
After all, as IBM's Savio Rodrigues points out, an open-source-friendly Microsoft no longer has qualms about embedding open-source software like MySQL into its products. In particular, Microsoft supports MySQL as part of its Azure cloud service...without paying Sun a dime for the privilege.
It's a completely legitimate way to offer open-source value to Microsoft customers, and is very similar to what Amazon is doing with MySQL.
However, as Rodrigues notes, it's not necessarily good for MySQL, or other open-source projects that could be used this same way:
The larger point is if Amazon, Microsoft, IBM, HP, Google, Cisco, EMC/VMware, or Oracle/Sun offer a simple and supported cloud service for running MySQL, Tomcat, JBoss, Mule, or Apache HTTP instances, what reason do customers have to acquire "enterprise subscriptions" from the vendors developing these open source projects? Until now, the value of an open source "enterprise subscription" has largely been access to support and access to administration and management tooling. In the case of MySQL, the former is provided by Amazon RDS and Azure SQL as part of the per-hour service. Again in the case of MySQL, the latter is rendered unnecessary or replicated through Amazon RDS and Azure SQL tools.
Consider it a super-friendly, and super-dangerous, bear hug.
For those who think that this affects commercial open source and not community-led open source, think again. Money and open source don't grow on trees.
The explosion of open-source development has directly correlated to the explosion of cash investments into open-source projects, starting with IBM's $1 billion commitment to Linux. MySQL, the database, would be a pale shade of what it is today without MySQL AB, the company that has funded the overwhelming majority of its development.
So, is this cause to castigate Microsoft? No. After all, it's really no different from what Amazon, Google, Apple, and others do with open source.
Rather, Microsoft's move should serve as a reminder to open-source companies that they need to upgrade their business models or risk being rendered irrelevant by the cloud and all that it enables vendors to do with open-source software.
After all, the protections that the GNU General Public License (GPL) and other open-source licenses offer in the traditional software world are essentially meaningless in the networked world, where software is used to create services, but isn't actually distributed.
This is as true for Red Hat as it is for open-source start-ups like Openbravo and Talend. Imagine if Amazon decides to start offering JBoss as a cloud service. Or Red Hat Enterprise Linux, for that matter (minus the trademarks).
It could happen. Actually, I'll go one step further: it will happen. It's just a matter of when.
This is why companies like IBM, Google, and increasingly Microsoft strategically invest in open source, but don't try to directly monetize open source. It's also why the "open-source companies" need to figure out a Plan B before Plan A gets taken from them.
Despite the broad and deep trend toward open-source software, it's telling that Red Hat remains the only large, pure-play open-source vendor.
Without a strong, standalone open-source leader, will commercial open source endure?
The obvious answer is yes, but there are reasons to think that the industry would benefit from a billion-dollar open-source company. Actually, several.
It might seem counterintuitive to suggest that open source, which by its very nature tends to be decentralized and bottom-up in its growth, would benefit by concentrating wealth in a few hegemons.
David is nice, but the fact is that Goliath generally wins.
Open source needs a few more of these.
Take baseball, for example. The New York Times on Monday reported on the importance of the spending power of the New York Yankees and Boston Red Sox to the overall strength of the American League. A rising tide may raise all boats. But in the case of baseball, a few dominant teams force the rest of the league to follow suit or die, a curse/blessing that the National League doesn't share.
The stronger Red Hat is, by analogy, the better-positioned it is to set the pace of spending and innovation for other open-source companies.
The same is true in football, i.e. soccer. "Soccernomics" traces the importance of the Manchester Uniteds, Arsenals, and Real Madrids for pulling in fans: fans flock to watch the big teams, either to cheer for them or against them. The prospect of cheering on Hull City to best Bolton simply isn't that appealing.
In a similar manner, Red Hat serves as a beacon for would-be open source buyers. It may be hard to get excited about buying into No-Name Open-Source Vendor X, but buying from an established brand-name vendor like Red Hat? Much more appealing.
The problem, however, is that Red Hat is still a minnow in the global software pool, and its fixed focus on baseline infrastructure leaves it ill-equipped to lead the open-source market. Most open-source start-ups simply don't need Red Hat to thrive, and they derive little value from a partnership with the company.
A lot of companies make money in the shadow of Microsoft. Not so in Red Hat's.
Nor is Red Hat a viable exit for most open-source companies. Google, IBM, and others actively contribute to open-source projects--and arguably contribute even more to the continued health of the commercial open-source ecosystem by offering healthy exits for open-source start-ups.
Tim O'Reilly called out this phenomenon years ago when he suggested that the likely exit for most open-source companies would be acquisitions by proprietary software vendors. This is good for the open-source companies, but it may not be good for open source.
It would be ideal to have a large open-source applications vendor, but it's unlikely we'll get one anytime soon, particularly since successful open-source companies keep getting swallowed by proprietary vendors before they can crack the $100 million mark, much less than $1 billion mark.
It's also possible that we don't need IBM-sized, pure-play open-source companies. After all, we have IBM and its ilk already funding open source.
It's equally likely that getting to such a size with a pure-play open-source model simply isn't possible.
But I think we need a few open-source hegemons, companies that can offer a clear alternative to Oracle and Microsoft for both buyers looking for open-source software solutions and vendors looking for open-source software partners. Such hegemons can also help to fund the growth of the next generation of open-source innovation.
But from where will they come? I'm not sure. Your thoughts, please.
In the battle of the open-source mobile platforms, developers have at least two choices: Google Android, which is open source but (relatively) closed development, or Symbian, which is open source...once it gets around to releasing the full source code.
Guess which one is winning?
You can't code me, but at least you can buy me.
(Credit: Google)Gartner expects Android to become the second-most popular mobile platform within the next few years as it continues to gobble up Symbian's declining market share.
But why?
Symbian has been dismissive of Google Android, as well as smaller upstarts like the LiMo Foundation, arguing that the latter is overly focused on middleware for wireless operators and the former is fake open source with more hype than substance.
All of which might be true, but the reality is that it seems to be working for Android. Google has been signing new handset manufacturers at a frenetic pace, while Symbian has been holding steady with Nokia...and that's about it.
Despite Symbian announcing new handsets, Google is actually shipping Android. There's a big difference between marketing and reality. Google Android offers the latter.
For all the buzz that Android gets from developers, its success owes more to handset manufacturers than to open-source developers. Handset manufacturers and wireless carriers are hungry for alternatives to surging Apple and declining Microsoft. And while others may not be seeing source code in copious amounts, handset manufacturers are apparently getting their fill.
More than this, though, Google gives them a safe, consumer-friendly brand. Symbian does not.
This is the reason Google Android is winning. It's not about developers--at least, not yet. Neither Symbian nor Android really offers developers open communities and open code.
No, the difference today is brand. Google has it. Symbian does not, and that's despite decade-long dominance of the mobile market.
Symbian still has a ways to go. It has a weak user interface (UI) that is supposed to get better, but that describes much that is wrong with Symbian today. Everything (source code, revamped UI, and resumption of market dominance) is always spoken of in the future tense.
Meanwhile, Google Android rolls on--not because it out open-sources Symbian, but rather because it out-executes it.
Some open-source software may not be open enough. While "open source" refers to software's underlying license and its adherence to the Open Source Definition, there are numerous examples of open-source projects that offer an open license but a relatively closed development process.
But is it open enough?
(Credit: Open Source Initiative)Java is one example people cite of "fauxpen-ness." SAP CTO Vishal Sikka on Monday called for a more open process for Java development, arguing that Sun too tightly controls Java's development. It's a complaint that has plagued the Java community for years.
Not that Java is alone. While Google gets plaudits for its open-source investments, some are quick to allege that Google maintains a closed Android community. The same sort of complaints have arisen over Google's management of Chrome and Chrome OS.
Even Red Hat, the quintessential open-source company, is primarily known for what it distributes, not what it develops. Red Hat, of course, works alongside IBM and other corporate and unaffiliated developers to write the Linux kernel, and scrupulously releases its software under open-source licenses.
But when it comes to development of its Red Hat Enterprise Linux distribution or development of its JBoss middleware or other technologies (e.g., KVM), good luck finding many significant external contributors.
MySQL? It's largely the same. The company (now Sun Microsystems) does virtually all of its own development, which is true of every commercial open-source company of which I'm aware. This is one reason Richard Stallman can unblushingly worry about MySQL's openness despite the fact that it uses his preferred GPL license.
Open source, but not necessarily open process.
There are very good reasons that Google, Red Hat, MySQL, and others keep a tight grip on their open-source development efforts. They are responsible--fiscally and legally--to their customers, and have to be able to guarantee quality and security. Understandably, they exercise some control to ensure the products they ship protect the integrity of their brands.
But such corporate open source indicates a real divide between "open source" as a license and "open source" as a wholly transparent way of developing and distributing software. The former is now common and relatively easy. The latter, quite simply, is not.
The companies that seem to do it best are those that don't rely on direct monetization of open-source software. In other words, if you aren't selling open source, it's easier to be open. Doc Searls captures this brilliantly by arguing "you make money because of [open source], not with it."
Examples abound. IBM is a good example. So is Google, though I agree with its critics that it can do better. Facebook, Oracle, and others also provide examples.
In the future, I think we'll see this "fauxpen-ness" fade as companies clearly separate their open-source efforts from their revenue models. Open source can provide a platform for monetization, but it isn't the best way to actually generate cash. Not for most companies, anyway.
Google CEO Eric Schmidt argues that competition is just a "click away." By opening up Google's access to personal data as well as the software that collects it, Google is adding substance to that claim.
Google's secret sauce? Operations.
It won't work to write better software than Google, because Google is not a software company. The only way to beat Google is through superior execution; through better operations.
The way to lose to Google? That's easy: try to sell software that Google is shoveling out the door as free (open source) software.
This thought hit me last week as Google announced the open-sourcing of its Closure tools. These are JavaScript compression tools that Google uses to build its own Web services like Gmail. Basically, Google was saying, "Here's how we build our software services. You can, too."
This follows on the heels of Google open-sourcing other software like Android ("Here's a free mobile operating system to help more people connect to our services"), Gears ("Here's how to run Google-like services offline"), and more, each opening up windows into the software that runs Google's services.
In many ways, Google is giving away the recipe to those that would like to build a Google clone.
The problem? Google is so much more than software.
In fact, one of the primary reasons that Google can write and open-source so much software is that it isn't a software company. Not even remotely. I could have every line of Google's software, both open source and proprietary, and I couldn't hope to compete with Google.
Google is what Google does with the software, and not the software itself.
Ditto for Red Hat. The company used to retain significant chunks of proprietary code in its Red Hat Network offering, but it has released that software under and open-source license in the last year. Doing so hasn't had any effect--positive or negative--on Red Hat's sales, because Red Hat isn't in the business of selling software anymore.
Red Hat, like Google, is in the business of providing services to customers, services enabled by software but which are much more dependent on IT operations and overall efficiency of execution.
And while both companies rely on open-source software to fuel those operations, Google, more than Red Hat, realizes that the conversation has moved on from open-source licenses to higher-order value, a theme that is going mainstream. Cloudera CEO Mike Olson captures this theme well:
The license terms attached to products have become secondary to the value it offers. People now are much more rational about how they adopt technology across the board. Open source is a detail, not a defining characteristic. At Sleepy Cat, we were proud to be an open source company. At Cloudera, I think of us as an enterprise software company that happens to be built on open source software.
Such sentiment would resonate well within the walls of Google's Mountain View headquarters, I suspect.
Even within their respective open-source communities, neither Google nor Red Hat company is particularly saintly. Red Hat has never waited on the Linux Standards Base or industry efforts to coordinate Linux distributions (like United Linux), but instead forged ahead with its own efforts...until the LSB simply adopted Red Hat's distribution as the standard.
Google, for its part, takes flak for dominating its open-source project communities like Android. Google's contributions (or lack thereof) to outside projects, like Linux, don't always mesh well with others in the industry.
To open-source community critics of Red Hat and Google, some advice: get over it.
The companies that spend the most time chumming around, talking up interoperability and the need for everyone to work together are usually the ones losing the race, a race whose rules may be written in software but whose victory depends upon execution.
Google and Red Hat have moved beyond software. Software enables their operations, but software doesn't define such operations. Google, for its part, is open sourcing Microsoft, one line of code at a time, and Microsoft hasn't a clue as to how to respond, because it only knows the old world: competition through better IP.
That world is gone. Open source has killed it. The new world is built on execution and superior IT operations. Google gets this. Red Hat gets this. Microsoft? Not so much.
Together we can figure this out
Despite Apple's tremendous success with the iPhone, we're still in the early innings of mobile adoption. As such, a strategy of "throwing-lots-of-things-against-the-wall-to-see-what-sticks" makes a lot of sense.
It's true of platforms like Google Android, but it's also true of applications.
Even on the iPhone, which reportedly drives $2.4 billion worth of applications in annual sales, very few application developers appear to be making much money. Zynga, creator of Farmville, is an exception, as BusinessWeek notes, doing more than $100 million in annual sales.
This isn't to suggest that developers should stop trying. Quite the opposite. Now is the time to try a range of applications to see what sells.
Google is following the same strategy with its Android platform. The company is happily promiscuous with its code, allowing and even encouraging fragmentation to see where the industry will take Android. Fragmentation enables handset manufacturers and others to find the best fit for Android in the market, rather than going the Apple route. ("If we build it, they will come.")
It's very possible, as Bill Weinberg notes, that such fragmentation and experimentation will result in Android getting greater play beyond mobile than it does in the smartphone market.
I suspect Google won't mind. As in other areas, it's using the broad-based, open-source approach to increase adoption of its services like Search, services which generate more than $22 billion each year.
It's an approach that works particularly well for a fast-follower: someone tracking the progress of an early market leader. An open-source strategy basically enables the industry to determine, by itself and for itself, what the market leader is missing and how to resolve the voids.
However, it's also a good way to generate developer interest and, hence, modifications and add-ons. Application developers might be well-served by open-sourcing their applications to encourage adoption and make their road maps a community affair.
There are over 4 billion mobile phones on the planet, with virtually no one outside of the wireless carriers and handset manufacturers making money from this extensive device reach. The market is ripe for software businesses, but first we need to experiment to discover what sells. Open source just might be able to help with that.
