Archive for the ‘business model’ Category

As the GPL fades …

Январь 28th, 2010

We’re continuing to see signs that the dominant GPL open source license may be fading from favor among commercial open source software players. The latest move away from the GPL comes from content management software vendor Alfresco, which is moving to the LGPL after originally releasing its code under the GPL three years ago. The reasoning for the shift, according to Alfresco CEO John Newton, is the company sees greater opportunity beyond being a software application, particularly given the emergence of the Content Management Interoperability Services standard. Alfresco won mostly praise for its move, and it does make sense given where open source is going these days.

I believe the emerging trend away from GPL and toward more permissive, mixable licenses such as LGPL or Apache reflects the broadening out of open source software not only throughout the enterprise IT software stack, but also throughout uses beyond individual applications, frameworks and systems. More and more open source software vendors are pursuing opportunities in embedded use or OEM deals whereby open source software often must sit alongside or even inside of proprietary code and products. Similar to what we’ve seen in the mobile space — where open source software and development are more prominent than ever, but end products with accessible code are not — open source is broadening out, but it is doing so in many cases by integrating with proprietary code.

We also see some debate about the community and commercial ups and downs of GPL as organizations contemplate the balance of the two and the best way to achieve commercial success with open source software. As Matt highlights, we are seeing a choice of non-GPL licensing in order to more effectively foster community and third-party involvement, but we also continue to see GPL as a top choice to similarly build community.

While the debate about community versus commercial benefit may not necessarily be prompting movement away from GPL, I believe another recent action may indeed do so. The latest series of GPL lawsuits are aimed at raising awareness, profile and legitimacy for open source software. While those bringing the suits — primarily the Software Freedom Law Center — have exhibited a reasonable approach and settled with past lawsuit targets, these suits and publicity may still serve to steer organizations making the choice to other licenses, including the LGPL, BSD, Apache and the Eclipse Public License.

Another factor is the GPL thumping that took place during the SaveMySQL campaign as the European Commission contemplated Oracle’s proposed (and now closed) acquisition of Sun Microsystems and the open source MySQL. I voiced my concern that the SaveMySQL campaign might jeopardize or de-value open source software projects and pieces in M&A, but I believe I’m actually in agreement with SaveMySQL leader Monty Widenius that the deal and process may end up tarnishing the GPL and its reputation in the enterprise.

As stated above, much of the movement we’re seeing away from the GPL has to do with the desire and opportunity to place open source software alongside, within, on top of or otherwise with proprietary software. Non-GPL open source licenses are also more flexible in terms of integrating and bundling with other open source software licensed under other, non-GPL licenses.

We anticipated this fade of GPL as covered in our report, The Myth of Open Source License Proliferation. Given its clout, durability and continued popularity in commercial open source (and with help from continued growth of GPL-licensed Linux) we believe the GPL will endure as a top open source license. However, given their flexibility and the ability to combine with other code, we see a number of other challengers — Apache, BSD, EPL and LGPL — rising while GPL dominance wanes. We’re also watching to see whether the AGPLv3 for networked software will provide new life for GPL-style licensing and community building in emerging virtualized, SaaS and cloud computing environments.


PlanetMySQL Voting: Vote UP / Vote DOWN

Comparing Cloud Databases: SimpleDB, RDS and ScaleDB

Октябрь 30th, 2009

Amazon’s SimpleDB isn’t a relational database, but it does provide elastic scalability and high-availability. Amazon’s recently announced Relational Database Services (RDS) is a relational database, but it doesn’t provide elastic scalability or high-availability. If you are deploying enterprise applications on the cloud (including Amazon Web Services), you might want to look at ScaleDB because it is a relational database and it does provide elastic scalability and high-availability.

Amazon describes SimpleDB by comparing it to a clustered database:

"A traditional, clustered relational database requires a sizable upfront capital outlay, is complex to design, and often requires extensive and repetitive database administration. Amazon SimpleDB is dramatically simpler, requiring no schema, automatically indexing your data and providing a simple API for storage and access. This approach eliminates the administrative burden of data modeling, index maintenance, and performance tuning. Developers gain access to this functionality within Amazon’s proven computing environment, are able to scale instantly, and pay only for what they use."

In other words, if there was a clustered database that was cost-efficient, simple, low-maintenance, and provided dynamic elasticity, that would be ideal. That is exactly what ScaleDB provides. Granted it isn’t as simple to use as SimpleDB (just look at the name, one is simple, the other is scale) but it does eliminate data partitioning and slaves/replication, both of which account for the bulk of the pain in clustering. ScaleDB also runs MySQL applications without modification.

Amazon, in a nod to SQL developers and MySQL applications, released Relational Database Services (RDS) this week. This too comes up short of Amazon’s ideal of a dynamically scalable and highly available MySQL database. Again, that is exactly what ScaleDB provides.

Comparing SimpleDB, RDS and ScaleDB

Function

SimpleDB

RDS

ScaleDB

Transactions

No

Yes

Yes

Joins

No

Yes

Yes1

Data Consistency

No (Eventual)

Yes

Yes2

SQL Support

No

Yes

Yes

ACID Compliant

No

Yes

Yes

Exploits EBS

No

Yes

Yes

Supports MySQL applications without modification

No

Yes

Yes

Dynamic Elasticity (w/o interrupting the application)

Yes

No

Yes

High-Availability

Yes

No

Yes

Eliminates Partitioning

Yes

No

Yes

Eliminates possible 5-minute data loss upon failure

Yes

No

Yes

Cluster-level load balancing

Yes

No

Yes

1The ScaleDB index delivers multi-table joins with the performance of a single table lookup using a technology that rivals materialized views but without the data synchronization headache.

2ScaleDB’s shared-disk architecture ensures data consistency across all nodes in the cluster.

ScaleDB is a storage engine that plugs into MySQL. It turns MySQL into a shared-disk DBMS, like Oracle RAC. ScaleDB, running on AWS provides elastic scalability, adding/removing nodes according to the number of database connections, all without interrupting any running applications. Also, because ScaleDB doesn’t rely on data partitioning-as you would with shared-nothing databases-the set-up and tuning are very simple.

SimpleDB and RDS are very good and they have their roles. However, I believe that ScaleDB is really the high-end solution, without the high-end price-that enterprise users of the cloud are looking for.


PlanetMySQL Voting: Vote UP / Vote DOWN

Open Source: Its Impact on Complementary Goods & Services

Июль 17th, 2009

A core economic principle is the Complementary Good . In short, when two or more things are used together, they are complementary. When the price of an item goes up, the usage of all of its complementary goods goes down. Similarly, if the price of an item goes down, the usage of all its complementary goods goes up. An example is the computer printer. Printers and ink are complementary goods. Proprietary ink products are extremely valuable—at one point ink delivered 60% of HP’s profits —so HP, understanding the principle of complementary goods, practically gives away printers because they make money on the ink. This is the classic razors and blades business model.

Businesses want to lower the cost of their products, while maintaining or improving their margins. This means commoditizing the pricing of complementary goods. Microsoft knows that by commoditizing PC pricing, they can maintain their pricing and margins. Similarly Oracle knows that by commoditizing servers and storage, they can sell more software, while maintaining their margins. In fact, at the Oracle World announcement of Exadata, Larry Ellison was talking with Mark Hurd (via video) and toward the end of the announcement Ellison says something to the effect of “…and we’ll work together to drive down the cost of Exadata.” (Note: it has been edited out of the official video from Oracle now). Hurd, caught of guard, says something to the effect of “well I don’t know about dropping the price.” Even on the initial day of the launch, Ellison is attempting to commoditize Exadata, because it is a complementary good.

Open Source Software (OSS) companies turn the commoditization weapon on themselves. The business rationale is to facilitate low-cost market entry, build a large userbase , and then monetize the business in other ways. Their other ways include add-on software, services, etc. They understand that by lowering the initial cost of acquisition, they will sell more complementary goods (or services). If you do it well, this model can be very powerful.

Now consider more than just the initial cost, consider the total cost of ownership (TCO), which includes ongoing services as well. The TCO of a database includes the costs of a collection of complementary services (installation, configuration, ETL, data partitioning, performance tuning, etc.). In our efforts to drive down the costs of complementary goods/services, it is natural that this would be a focus. In fact, while hardware and software costs are declining, services costs are increasing, due to increasing human costs.

ScaleDB, we recognized that services are the one component in TCO that has been increasing over time, while all other components are decreasing. If you have an individual being paid $100K per year, with a fully loaded cost of $135K, and you juxtapose this against free software and declining hardware and storage costs, you can see how it is becoming an increasingly critical component of TCO.

Recognizing this trend, we at ScaleDB have set out to actively lower the amount of effort required for these complementary services. We do this by addressing each step in the process that we influence. The biggest factors in database services are set-up, maintenance and tuning.

ScaleDB uses a shared-disk architecture that eliminates the need to partition your data. All of the data is stored in one collection and each of the nodes in the cluster has full access to the data. This dramatically simplifies both set-up and maintenance, since there is no need to partition or repartition. The shared-disk architecture also dramatically simplifies the tuning process, since tuning and partitioning are intimately linked. Also, the shared-disk architecture provides dynamic cluster-level load balancing. This inherently addresses temporal shifts in usage and also longer-term evolution of usage patterns. In short, it addresses these challenges without you worrying about them. More information about the pros and cons of the shared-disk architecture are available in this white paper .

Based on the economic law of complementary goods, software companies have traditionally pushed the commoditization of complementary hardware. OSS then forced commoditization of software to benefit complementary software and services. Now we are actively commoditizing complementary services. The net result of all of these trends is a decreasing TCO and increased use.