Canonical, the company behind Ubuntu, has often been criticised for keeping their bug reporting and collaboration tool, Launchpad, closed-source. Today, Canonical has started opening up Launchpad by releasing its first open-source component, Storm. “Storm is an ORM that simplifies the development of database-backed applications in Python, especially for projects that use very large databases or multiple databases with a seamless web front-end”, said Gustavo Niemeyer, lead developer of Storm at Canonical. “Storm is particularly designed to feel very natural to Python programmers, and exposes multiple databases as /stores/ in a clean and easy to use fashion.”
Maybe Mr. Shuttleworth’s plan of creating a central “patch & fix” tracker comes to fruitition now. While Storm is not really the heart of LaunchPad, it is a beginning. Cheers.
The stated reason for keeping LaunchPad proprietary is so that it remains a central tracker. Canonical worries that if they opened LaunchPad completely, there would be several fragmented trackers with no common index. Their plan is to open only the pieces of LaunchPad that may be useful in different kinds of projects. Storm is not being released as a component of LaunchPad, but as a generic ORM for Python.
The licensing issues surrounding LaunchPad are interesting. How can we reconcile the ideals of free software with software designed for a single worldwide deployment? How do we allow copying, modification, redistribution, and test deployment while restricting production deployment? How do we “fork” the production deployment?
[q]Storm is not being released as a component of LaunchPad, but as a generic ORM for Python.[/quote]
Are you suare about that?
From http://www.ubuntu.com/news/storm-python-orm-open-sourced:
New Python-based database communication tool represents first open source component of Launchpad
The way that I am hearing it in Python circles, it is being taken as a generic ORM for Python.
The discussions that I have encountered are all about how this might or might not impact SQL Alchemy.
I’d give it a Hip! Hip Hurrah! except that my beloved Python suffers from *too much* choice, IMHO, largely due to the ease with which one can reinvent the wheel in it.
And how do we ignore the past with the kernel community’s experience with Bitkeeper? How are we assured that proprietary products leveraging the open source community with reciprocal goodwill do not wind up holding them in headlock down the road?
Shuttleworth’s track record is unquestionably worthy of a benefit of the doubt as to his intentions with launchpad and I’m certainly not implying an ulterior motive, but the long-term big picture can’t be ignored. Bitkeeper was considered a good idea at the time and certainly helped accelerate kernel development, but if they had anticipated the future issues and conflicts that would arise, would they have chosen to go with it?
I’m one of those frowned-upon pragmatic types that believes FL/OSS and proprietary both have their place, but even I’d have concerns with open projects depending upon any closed/proprietary links in the development chain.
“””
Shuttleworth’s track record is unquestionably worthy of a benefit of the doubt as to his intentions with launchpad and I’m certainly not implying an ulterior motive, but the long-term big picture can’t be ignored. Bitkeeper was considered a good idea at the time and certainly helped accelerate kernel development, but if they had anticipated the future issues and conflicts that would arise, would they have chosen to go with it?
“””
Not to be indelicate. But Larry McVoy was always an ass. That’s a difference worth noting.
BTW, despite my previous, flippant response, I agree with you.
The whole BitKeeper thing was doomed to failure from the start. Linus analyzed the technical aspects flawlessly. But he misjudged the impact of his decision upon his team. (Unusual for him.) I’m sure he knew that there would be conflict. But he assumed it would all blow over.
In all fairness, at the time, Linus was under a fair amount of pressure to do *something*. He had found CVS to be unsuitable. But his own system was not scaling. More to the point, his system was not allowing Linus to scale. Developers were frustrated at being “ignored”. Linus was frustrated because his devs were frustrated… when he was already doing his best.
Then “the snake” showed up with BitKeeper. Oh, sure, we’ll grant you a free use license. You and your devs will love it. I give you my word.
The rest of the story is, as they say, history.
The happy ending is that after all the ugliness and killing was over, Linus was put on track as to what he *really* needed, and rewrote the features of BK that were of benefit to the project in a few days. And the rest was hammerred into shape by others in a few months. So the whole thing was a hugely beneficial learning experience, in all sorts of ways.
To me, that episode is the ultimate argument for every cloud having a silver lining.
But anyway, yeah, accepting code into the great OSS ocean is one thing. Using it for infrastructure is quite another.
Edited 2007-07-11 04:33
What I don’t get is: Let’s say LaunchPad is opened up completely, and yes the “worst fears” that there will be several fragmented trackers come to fruition. What is preventing Canonical from sticking to their specific index? Correct me if I’m wrong, but Ubuntu (and derivatives) are currently the only people using LaunchPad anyway, right? So who cares if some other people want to go make their own index? Ubuntu et al can keep chugging away with their own implementation. What’s the need for this central control over everything? It’s very un-open-source-esque.
Isn’t it obvious? He doesn’t want people wasting effort. He wants to help people collaborate. He doesn’t want 1000 independant Bugzillas running around the internet not helping 1000 projects work together. He wants to help open source software. Whether you agree with the methods or not, that’s what he wants to do.
The problem is that bugs need to be filed in many different places, and status updated on each one. Launchpad is designed to keep track of all of those places. They don’t want things to get even further seperated. A better solution is a distributed system where everything communicates with each other, Shuttleworth said this, and I believe its true. Shuttleworth says the next best thing is a centralized system like Launchpad. I’m not sure, but I think it is better then the current system.
Canonical worries that if they opened LaunchPad completely, there would be several fragmented trackers with no common index. Their plan is to open only the pieces of LaunchPad that may be useful in different kinds of projects.
I hope that is the case. IMHO it’d be good for open source product development if consolidated their bug/localization/etc systems.
The stated reason for keeping LaunchPad proprietary is so that it remains a central tracker. Canonical worries that if they opened LaunchPad completely, there would be several fragmented trackers with no common index. Their plan is to open only the pieces of LaunchPad that may be useful in different kinds of projects.
Ah, the “Java excuse”, the “We can not open source because it will fragment”. Sun used that for years.
Miguel.
“””
Ah, the “Java excuse”, the “We can not open source because it will fragment”. Sun used that for years.
“””
With all due respect, it remains to be seen whether that will happen.
Storm shows sort of Python functionality cannot be done in released versions of Php, mainly OOP thing, even javascript is better OOP language than Php
But in another hand… you can’t just upload py files and run it on web host… here where Php won, let’s hope for better OOP and better Unicode for Php 6
Python and PHP are two different beasts, designed for different things. They can’t really be compared directly.
Both claim to support OOP right? a one can’t compare one implement is three languages!?
some people who have not used launchpad seem to assume that it is basically similar to bugzilla. it is actually more like sourceforge. it is a complete set of hosting, issue tracking, user/team management, etc service.
Orm means snake in Swedish.
It always seems to me that ORMs are a roundabout way of writing SQL without writing SQL and encourage the programmer to do things in the least efficient way possible. SQL is awesomely powerful, but largely wasted by the constrictions of the ORM. And the contorted abuses of named method arguments in most ORMs end up looking like some mangled form of SQL anyway.
Add in the database neutrality that most ORMs seem to impose, and you’ve effectively turned PostgreSQL into a crippled version of SQLite.
In return, you get to be pure in your object-orientedness, and some protection from SQL injection attacks.
I was just looking around for some choice words about ORMs written by Alex Martelli (I think), about how they are just a way for people to avoid learning SQL, but can’t seem to find it.
I wonder what other people think about what I just said.
Edited 2007-07-11 15:17
I don’t agree at all. Rails, Django et al. wouldn’t exist without ORM layers. That’s because it’s not natural to have to think OO for your application and then think SQL for data access. You’re going to end up wrapping common SQL calls in methods, then if you’re a good programmer think about how to group those methods in classes. The only thing you lose is direct control over the efficiency of your queries, but then an ORM project like activerecord takes over the responsibility of making those queries as efficient and delayed as possible. That’s a good thing!
The background on this ORM is that Launchpad is built using a patchwork of technologies from the bizzaro Zope world. They have a crazy Zope Object Database. It stores … Zope objects. No, it actually stores pickled Python objects, which are accessible through a URL structure: http://site.com/container/object/object_method . It requires tons of memory and caching to work well, and to collect objects you either walk the object structure or request objects by searching an “index”, a relational mapping of the object database! It’s supposed to be easy for a Python programmer to grasp, but it doesn’t scale well and a good ORM is just as easy to use and promotes efficient queries.
“””
The only thing you lose is direct control over the efficiency of your queries, but then an ORM project like activerecord takes over the responsibility of making those queries as efficient and delayed as possible. That’s a good thing!
“””
To add to this line of thought, a *good* ORM does make it easy to drop to SQL, when required, and do that left outer join when you really need to.
I do a lot of reporting work from large sets of tables, generating reports which may easily be several hundred pages, which is probably a worst case scenario for an ORM.
That no doubt colors my views. I appreciate the response and welcome others. 🙂
Well an ORM can do a lot more than just cripple your SQL. Hibernate as an example provides nice features for caching objects and collection in various places.
It also provides HQL which is a VERY nice extension to SQL letting you do queries on your OO Model rather than your DB Schema.
select cust
from Product prod,
Store store
inner join store.customers cust
where prod.name = ‘widget’
and store.location.name in ( ‘Melbourne’, ‘Sydney’ )
and prod = all elements(cust.currentOrder.lineItems)