Slashdot Mirror
Canonical Begins To Open-Source Launchpad
kripkenstein writes "Canonical, the corporation behind Ubuntu, has begun to open-source Launchpad. Canonical has been criticized for not doing so earlier. The first component of Launchpad to be open-sourced is Storm, described as an 'object-relational mapper for Python.' A tutorial with many examples is available. The license for Storm is the LGPL 2.1. Inspection of the source files shows they contain the common phrase, 'either version 2.1 of the License, or (at your option) any later version,' meaning that Storm is LGPLv3-compatible."
Now, you might be wondering why anyone would open source anything at all. And my simple answer to that is this: Prior to today, if someone said 'Launchpad' to me, it would be the Ducktales character. As soon as this application is open source, it's going to become something I installed on my box and played around with for a while. And that's the difference, if it's proprietary, you better be prepared to sell it or it's going to die a death of obscurity without anyone even hearing about it.
People have the choice not to open source software and oftentimes, it's for very good reasons. I don't think this case is any different as the Wikipedia article states: Mark Shuttleworth responded personally to this criticism stating that Launchpad needs paid-programmers to continue the development of the Launchpad platform and that there would be no point in developing multiple versions of Launchpad due to the probable incomparability of the forks [2]. Mod me as flamebait if you want but the original creators deciding that they value the quality or single source of code is just as valid as any other for delaying a release under an open source license.
Canonical isn't stupid and, yes, they're making money. According to Wikipedia, their 50 person company has an annual revenue of $10 million. Which isn't too shabby. I think these guys are genuinely interested in being both an active member of the open source (Ubunutu) and commercial (Project Landscape) worlds. Isn't it obvious who their thinking of when they put: 'either version 2.1 of the License, or (at your option) any later version,' which is pretty much proof that they have companies in mind who refuse to proceed to GPLv3 (like Microsoft and the cadre of companies that have paid them for software patent protection). You can paint this move as evil, brilliant, successful, intelligent or any of all of them. To me, I trust these guys as Ubuntu has made open source a little more accessible to the world and I really believe that not only do they know what they're doing but they're going to be around for a while. That's good news for software and (at least in my opinion) therefor good news for everyone.
My work here is dung.
Anyone know how Storm compares to SQLObject? They appear to achieve the same goal.
Sam! If you will let me be,
I will try them.
You will see.
ORM is great! ... until you you have a couple hundred thousand rows. Then it's slow. ... until you have a couple million rows. Then it's unbearable.
I love ORM for smaller applications, but there's always a point where heading down the hall to say "hi" to the local DBA is a good idea. And beware, redesigning the DB from the ORM to your own schema can be extremely painful. How close the ORM schema is to "pleasant" depends highly upon the package you use.
This is from someone who is trying to perform queries on someone else's database designed with Hibernate. One that has 12 million rows (average row size, 9KB). Which has been running my simple query for 40 minutes.
The reason they don't opensource it because there should only be one Launchpad, or you get all kinds of complex problems that are totally unnecessary. The point of Launchpad is to have a central system to manage things. Why do you need your own Launchpad, when it's better for it to be centralized?
> ORM is great! ... until you you have a couple hundred thousand rows. Then it's slow. ... until you have a couple million rows. Then it's unbearable.
> This is from someone who is trying to perform queries on someone else's database designed with Hibernate. One that has 12 million rows (average row size, 9KB). Which has been running my simple query for 40 minutes.
Don't get me wrong, bad database design is bad database design whether it is ORM or any other technology. Something tells me that based on the average row size of 9KB, I'm thinking this table does not really follow good relational design principles (1st normal form, I'm guessing). I've had a project where the data grew quite quickly, quicker than we had anticipated and the database needed optimized. Fortunately, since we were using Spring backed with Hibernate, we had interfaces defined for all of our persistent objects. Our solution was to use iBATIS to get some more granularity with our database queries, build some stored procedures (so that the query plan would be compiled) and add an index or two. The iBATIS classes were retro-fitted to implement the interfaces for the hibernate objects and then all we had to do was tell Spring to use the iBATIS objects rather than the Hibernate objects. Surprisingly, all of the unit tests passed and post-install, we increased our performance quite drastically. The whole project went as smooth as you could hope and I was pleasantly surprised because I really didn't think it would work out. I've been a fan-boy ever since. I still start with hibernate because it does help cut-down the design time, and I believe that "premature optimization is the root of all evil" (Knuth) -Wes
Your statement is just plain stupid.
Decent ORMs do nothing but map object operations into SQL statements. SQL from an ORM tool is not going to magically work more faster or slower than a hand-written one.
Again, decent DB schemas (i.e. fairly normalized ones) map nicely into object models (hell, ER-diagrams used to model relational tables map directly into object diagrams). It's the databases with weird tables without PKs and strange stored procs which do not map well.
I've worked with Hibernate application handling OLAP operations on 10 terabytes of data without any problems.
It's difficult to see, in this day in age, ones who lead by example. This should be considered a rare (yet inspirational) occurrence of true leaders - ones who practice what they preach.
Thank you, Canonical, for doing what you do.
Sincerely,
A proud GNU/Linux user.
It is pitch black. You are likely to be eaten by a grue.
Correct Usage: Human writes SQL schema, then integrates the ORM. As long as human doesn't do silly things in the programming language, we have success. Database objects become much easier to use, and speed is fast.
Incorrect Usage: Human writes an object spec. ORM auto-generates SQL schema. Human blindly uses machine-generated ORM bindings without understanding underlying SQL. Database gets mildly large, then human complains "the stupid thing is slow".
If ORM is done for convenience, great! That's what I use it for.
If ORM is used in lieu of understanding how SQL works, you could be headed for trouble.