I Just read on Daring Fireball that the judge has denied TechCrunch's claim for preliminary injunction against their former tablet partners and makers of JooJoo, Fusion Garage.
Gruber claims that "Mike Arrington gets smacked around in the first round of his lawsuit over the JooJoo/CrunchPad. In short: TechCrunch didn’t get much in writing regarding their “partnership” with Fusion Garage to develop the product, and, well, they should have."
He then goes on too snarkily add, "Curiously, I’ve seen no coverage of this decision on TechCrunch."
Because I am admittedly fascinated with the case, I actually took the time to read the judge's decision. Perhaps Gruber's snark would have been appropriate if his "in short" was anywhere within several miles of the truth regarding the decision. Honestly, the whole JooJoo thing seems like such distant and irrelevant news in light of the iPad, and soon Android and Chrome OS tablets. But its fascinating to me that Gruber feels compelled to totally misrepresent what the judge said.
The real "in short" of the judge's decision is this. The judge said that the preliminary injunction request was denied, essentially because it was not specific enough about how much profit there would be in the device, if any at all. He also said that there was no evidence that if TechCrunch prevailed in the final case that the injunction was necessary to insure that TechCrunch could receive a recovery. There were additional and more detailed legal conclusions, but they were all narrow and only relevant to immediate injunctive relief. So TechCrunch's request that 100% of the revenue of the *sales* of the device was overreaching, and legally insufficient and was therefore denied.
But the judge, then went on to spend quite a few pages laying out that it was likely that TechCrunch was in a partnership/joint venture with defendant FusionGarage, and that it was likely that Fusion Garage had breached its fiduciary duty, contrary to their assertions. It seems *very* likely to me, from reading the decision, that TechCrunch will win the case.
Specifically, the judge said, "Accordingly, TechCrunch has made a credible showing that it may be able to establish the existence of a joint venture under which Fusion Garage owed it certain fiduciary duties. Such duties may have precluded Fusion Garage from proceeding to market with the joojoo without taking appropriate steps to dissolve the relationship and to compensate TechCrunch."
If there were any money to be made, it is likely that TechCrunch would be getting a nice piece of it. Alas, given the circumstances, a victory here would be pyrrhic. The JooJoo will never make money and so the whole thing is moot. What's not moot is that Gruber, for some strange reason felt compelled to summarize the judge's decision in a patently false manner. Re: Daring Fireball, caveat emptor.
Sunday, August 29, 2010
Thursday, August 26, 2010
Death of the Relational Database 2010
Back in 2008 I wrote a piece called Death of the Relational Database. It was one of the most popular pieces I have written, and for many reasons the subject matter is one in which I have an ongoing interest. As a result I wrote current piece to organize my thoughts for a talk I have proposed for the South By South West Conference. If you’d like to hear me talk (or argue about this subject with me) you can vote for my talk on the SXSW Panel Picker and meet me in Austin. Voting ends on August 28th.
Overview
People have begun to realize the enormous gap between the relational database abstraction and the way people actually think about information. To be clear, I am not suggesting that relational databases will stop being used or that they are going to go away, but that developers are going to stop thinking of their data in relational database terms.
Most Data Models Are Simple. Storing Them Isn’t.
Everyone from non-technical users to sophisticated developers thinks about information in a pretty simple way. There are objects, and there are connections or relationships between objects. For example if you have two objects, a cup and a table, the relationship between them might be “sitting on”, indicating that the cup is sitting on the table.
What makes this model so sturdy is that we can continuously add new objects: tables, cups, chairs, floors, table cloths, etc. And we can add infinite relationships, such as sitting on, sitting under, covering, etc. Computer scientists, and now, thanks to Facebook, everybody else, refers to this structure as a graph.
And while the graph model is incredibly compelling, the problem is that when programmers write programs that access data in memory, they are able to write code that models data as a graph of objects and connections. But when programmers write programs that need to store persistent data on disk, they have generally needed to use the much less natural and more complex relational database.
Historically, the reasons for using a different model from how we naturally think about data when storing things on disk boils down to the fact that the algorithms for implementing relational databases have been very, very efficient. They have worked well, they can guarantee data integrity, and they have been the best we’ve had in terms of performance. These reasons, by the way, are also the reasons, the underlying relational database technology will be around for a long time.
We're Really Talking About The Death of the Relational Database Abstraction
So when I talk about the death of the relational database, what I am actually talking about is not the death of the technology, but the death of the *abstraction* as a way that programmers and people think about data. The reason this death is occurring is because what programmers really want is to think about data in the most natural way possible. In the last several years that has become more and more feasible. Just as all software today actually runs in machine language, we have moved away from that as a model for thinking about code. We have become more abstract and now think in terms of much higher level languages that are more effective for programming.
Similarly, relational databases will continue to sit inside and under many data stores. But we are starting to see abstractions that move data management closer to how we think about organizing data and further away from the relational storage model. Sometimes those more natural abstractions sit on top of relational databases, with things like Ruby On Rails Active Record. And sometimes these abstractions are implemented in entirely new engines. But the implications of having a more natural way of thinking about and organizing data are profound.
The Web Is Really a Giant Graph Database
As an example of how profound storage and data modeling abstractions are, consider that the World Wide Web itself is a form of a graph database. You have objects, in this case pages, that are connected by links. Of course all of the objects are of the same type, i.e. pages and all of the connections are of the same type, i.e. links. Nevertheless, the Web serves as the quintessential example of the power of thinking about data in a more natural way. Improving the database abstraction in the database world will have similarly profound implications. Just as the leverage available to us increased massively when we went from machine language to assembler, and from assembler to C and from C to C++ and then to Java, so too will abstractions in our data model provide similar leverage and acceleration of innovation.
My belief is that databases will, over time, become more like graphs. There are several early products and technologies that implement graph database technology, including the one my company is developing. This talk, however, is not about whether technology A or technology B is going to win. There will, no doubt, be a proliferation of technologies, and I suspect there may not be any clear winner for some time, if ever.
But data storage technology is starting to move closer to how people think about data instead of requiring people to model their data the way the computers do.
What About The Semantic Web?
Now some of you may think these ideas are familiar. In fact if you have looked at any of the technology underlying what is known as the Semantic Web, the idea of the graph for data storage is not new. Tim Berners-Lee and the W3C have been promoting the concept and developing the standards for more than ten years. But the truth is most of the technological standards that underlie the official Semantic Web specifications have not taken off. It is my view that they never will. What is the difference between what I am saying and what the Semantic Web is about?
The key difference is the ideas I am talking about are a way to look at data management that can and will take shape in many forms. They are not tied to any specific implementation details. On the other hand, the W3C’s Semantic Web is a set of very specific standards for how a Web scale graph of objects should be implemented. The problem is that people have seemed to like the ideas, but not the standards so much.
For example, Facebook introduced the concept of the social graph and more recently a broader graph of things in the world. But until recently, Facebook used none of the Semantic Web standards, and with its latest technology uses only a tiny sliver of it. The reason is that the Semantic Web standards are, to be honest, not very good at speaking to the needs of regular developers. As a result some of the fantastic ideas in the Semantic Web are dying under the weight of an obtuse implementation specification.
Other Models
Of course, as I see it, a pure graph is the best way to represent information, but there are other non-relational ways to think about data that are starting to take off as well. Key value stores and document databases like MongoDB and CouchDB are becoming incredibly popular. This is, in part, because they perform really well, but also because for many applications, they line up much better with the way people think about their data than relational databases do.
Better Abstractions Means Better Results
Perhaps the most important point here is that the process of improving our data abstractions and moving away from the relational model, a process that has already begun and will accelerate, is going to have profound effects on developer productivity, and most importantly on the types of applications that are possible. Just as every new class of programming languages has provided more leverage and more useful applications, the same types of explosive advances will come from better more natural data storage abstractions.
Coda
Again, if you’re coming to South By South West (or even if you're not) and you think the subject is interesting, you can vote for my panel here by August 28th.
Overview
People have begun to realize the enormous gap between the relational database abstraction and the way people actually think about information. To be clear, I am not suggesting that relational databases will stop being used or that they are going to go away, but that developers are going to stop thinking of their data in relational database terms.
Most Data Models Are Simple. Storing Them Isn’t.
Everyone from non-technical users to sophisticated developers thinks about information in a pretty simple way. There are objects, and there are connections or relationships between objects. For example if you have two objects, a cup and a table, the relationship between them might be “sitting on”, indicating that the cup is sitting on the table.
What makes this model so sturdy is that we can continuously add new objects: tables, cups, chairs, floors, table cloths, etc. And we can add infinite relationships, such as sitting on, sitting under, covering, etc. Computer scientists, and now, thanks to Facebook, everybody else, refers to this structure as a graph.
And while the graph model is incredibly compelling, the problem is that when programmers write programs that access data in memory, they are able to write code that models data as a graph of objects and connections. But when programmers write programs that need to store persistent data on disk, they have generally needed to use the much less natural and more complex relational database.
Historically, the reasons for using a different model from how we naturally think about data when storing things on disk boils down to the fact that the algorithms for implementing relational databases have been very, very efficient. They have worked well, they can guarantee data integrity, and they have been the best we’ve had in terms of performance. These reasons, by the way, are also the reasons, the underlying relational database technology will be around for a long time.
We're Really Talking About The Death of the Relational Database Abstraction
So when I talk about the death of the relational database, what I am actually talking about is not the death of the technology, but the death of the *abstraction* as a way that programmers and people think about data. The reason this death is occurring is because what programmers really want is to think about data in the most natural way possible. In the last several years that has become more and more feasible. Just as all software today actually runs in machine language, we have moved away from that as a model for thinking about code. We have become more abstract and now think in terms of much higher level languages that are more effective for programming.
Similarly, relational databases will continue to sit inside and under many data stores. But we are starting to see abstractions that move data management closer to how we think about organizing data and further away from the relational storage model. Sometimes those more natural abstractions sit on top of relational databases, with things like Ruby On Rails Active Record. And sometimes these abstractions are implemented in entirely new engines. But the implications of having a more natural way of thinking about and organizing data are profound.
The Web Is Really a Giant Graph Database
As an example of how profound storage and data modeling abstractions are, consider that the World Wide Web itself is a form of a graph database. You have objects, in this case pages, that are connected by links. Of course all of the objects are of the same type, i.e. pages and all of the connections are of the same type, i.e. links. Nevertheless, the Web serves as the quintessential example of the power of thinking about data in a more natural way. Improving the database abstraction in the database world will have similarly profound implications. Just as the leverage available to us increased massively when we went from machine language to assembler, and from assembler to C and from C to C++ and then to Java, so too will abstractions in our data model provide similar leverage and acceleration of innovation.
My belief is that databases will, over time, become more like graphs. There are several early products and technologies that implement graph database technology, including the one my company is developing. This talk, however, is not about whether technology A or technology B is going to win. There will, no doubt, be a proliferation of technologies, and I suspect there may not be any clear winner for some time, if ever.
But data storage technology is starting to move closer to how people think about data instead of requiring people to model their data the way the computers do.
What About The Semantic Web?
Now some of you may think these ideas are familiar. In fact if you have looked at any of the technology underlying what is known as the Semantic Web, the idea of the graph for data storage is not new. Tim Berners-Lee and the W3C have been promoting the concept and developing the standards for more than ten years. But the truth is most of the technological standards that underlie the official Semantic Web specifications have not taken off. It is my view that they never will. What is the difference between what I am saying and what the Semantic Web is about?
The key difference is the ideas I am talking about are a way to look at data management that can and will take shape in many forms. They are not tied to any specific implementation details. On the other hand, the W3C’s Semantic Web is a set of very specific standards for how a Web scale graph of objects should be implemented. The problem is that people have seemed to like the ideas, but not the standards so much.
For example, Facebook introduced the concept of the social graph and more recently a broader graph of things in the world. But until recently, Facebook used none of the Semantic Web standards, and with its latest technology uses only a tiny sliver of it. The reason is that the Semantic Web standards are, to be honest, not very good at speaking to the needs of regular developers. As a result some of the fantastic ideas in the Semantic Web are dying under the weight of an obtuse implementation specification.
Other Models
Of course, as I see it, a pure graph is the best way to represent information, but there are other non-relational ways to think about data that are starting to take off as well. Key value stores and document databases like MongoDB and CouchDB are becoming incredibly popular. This is, in part, because they perform really well, but also because for many applications, they line up much better with the way people think about their data than relational databases do.
Better Abstractions Means Better Results
Perhaps the most important point here is that the process of improving our data abstractions and moving away from the relational model, a process that has already begun and will accelerate, is going to have profound effects on developer productivity, and most importantly on the types of applications that are possible. Just as every new class of programming languages has provided more leverage and more useful applications, the same types of explosive advances will come from better more natural data storage abstractions.
Coda
Again, if you’re coming to South By South West (or even if you're not) and you think the subject is interesting, you can vote for my panel here by August 28th.
Subscribe to:
Posts (Atom)