So many of the triaged bugs HAD TO be triaged due to the conversion from SourceForge to LaunchPad. Presenting the big number of bugs triaged thanks to LaunchPad is quite misleading.

Mark Shuttleworth says: Ah. So if we export all of the data through an open protocol like IMAP, or web services API’s, then you would be happy? Good! Because that’s what we are working on. There’s no attempt to lock anybody’s data into Launchpad.

Mark Shuttleworth says: None of the linux distributions, including Ubuntu, Red Hat or Novell, can compete with Microsoft and Oracle on financial terms. We have to collaborate with one another and with the free software community if we want to have a chance of changing the way the software industry really works today.

Ciao,
Paolo

In my eyes I see the situation as:

Community: “Mark we want to help you make the tools we use better.”
Mark: “You can not help yet, please bare with us while we try and add things _we_ think are needed.”

Now you can faff about worrying about fragmentation, or you can ride the FOSS train by the seat of your pants and open the code, how ever ugly and embarrassing it is and show us all what it means to put your fears aside and trust the community that develops your software.

Regards, Martin

I see the way forward as a Foundation Board (free to join as individual contributors, not permitted for companies) that establishes community standards on all collaboration resources.

Such a standard should include what kind of information should be contained in a bug report, and this could in turn be implemented as a RDF resource. As far as I have seen LaunchPad already provides RDF resources for bugs. This way there would have, if needs be, an easy transition between different project infrastructures: maybe one will be able to take all the bugs (closed or open) her/his project has on Source Forge and have them automatically imported, as a batch, into LaunchPad or CollabNet.

For project infrastructure there are also tools like Maven, which ads the goodness of dependency management. We should check the effectiveness of Maven and similar tools, find their weakest spot and make a request to the responsible team to improve that feature.

I also think we need to research more thoroughly a free software development methodology. We do not like some Agile or XP programming ways of doing things, so we need our own methodology/-ies. There are some academic studies on our development model but they are scatterd across different web sites. The idea is that we do need a more structured, integrated documentation tool on how we do/should work.

This research is needed to prepare the infrastructure we will use 2,4,8 years from now, when both the number and the diversity of contributors to our community will grow immensely.

I’ve really held off writing this, because I’m a huge Ubuntu fan: the software, the project, the community and the core ideals. But I squirm whenever the issue of Launchpad arises. Frankly, its proprietary status is excruciatingly embarrassing to those of us who proselytize Ubuntu. It’s a direct contradiction of the core ideals of the project. Like others above, I have no answer to critics who gleefully point out that at the heart of the Ubuntu project there exists a glaring, and worse *willful*, philosophical inconsistency.

Please fix this Mark. Having achieved so much, it would truly be a tragedy if Ubuntu lost support and momentum over this issue. Once the negative meme is established, it’s going to be really hard to correct it. Ubuntu has so much good will at present, please don’t risk throwing that away. If the Ubuntu star fades, it could be years before there’s anything comparable to replace it.

It seems absurd, but Launchpad’s proprietary status is a probably a bigger threat to Ubuntu than Microsoft or any other proprietary vendor ever could be. The application’s licensing status is compromising the apparent integrity of the Ubuntu project in a very public way and giving ammunition to its critics that they would never have had if it were open/Free.

Personally, I do trust you and Canonical to eventually do the right thing. But I’m very concerned that the Ubuntu project’s reputation will be irreparably damaged before those right things are done.

It seems fairly clear that Canonical’s hold on Launchpad is primarily for pragmatic (i.e. management and control) reasons rather than for commercial or other reasons. While many will understand and sympathize, even such worthy expedience can’t justify such an apparently hypocritical situation.

Yours sincerely …. (I’m posting this anonymously, although you can see from my mail address who I am).

Mark Shuttleworth says: I appreciate the sentiment. Your email address @gmail.com suggests that you do use web services that don’t publish their source code. I would very much like to establish a best practice for open web services, including publishing the source code. I want to tap into that talent pool, there are lots of folks with interesting ideas for Launchpad. At the same time, LP is not a federated solution. It would get worse for users like Inkscape, not better, if there were lots of instances of Launchpad to choose from. Folks are all entitled to their opinions, and entitled to choose the tool they want to use. About the only software project hosting service I know of that is totally open is GNU Savannah and I can recommend it heartily if that’s the most important thing to you.

We’ve debated internally at great length on how best to move to a fully open sourced Launchpad. We have good people who care deeply about free software and contribute a lot to the free software community, both through Ubuntu and directly upstream in many projects. Those who think that Launchpad’s licensing is the result of a lack of care for free software, or a lack of experience, or a lack of insight, or a “willful inconsistency”, are mistaken. We want what’s best for the projects that use Launchpad.

I intend to make sure the code is published. I expect there will always be some things that are only relevant to Canonical, and other things which make sense as independent projects. LP is one big mishmash of those things right now, because we built it quickly with a single user in mind. In time, we will tease those things apart. Right now, my priority is to continue to bring best practices to the projects that use LP, to make them more efficient and easier to manage.

In the short term, we intend to expose all data in LP via API’s so that we can at least rigorously address the concerns people may have about data lock-in. It’s certainly not our intent to lock anyone in, we’ve never refused a request from a project for a dump of their data, but it would be better if that access were available in a standard set of API’s 24×7.