Comments on: Ubuntu Launchpad to go open source

Canonical plans to open up its project-hosting and collaboration code, designed to make it "easy to share code, bug reports, translations, and ideas across projects," on July 21.

[jspaleta]

Correction, only parts of Launchpad are going to be opened.

The Soyuz component is not. How important is that component? Soyuz is the component that does absolutely everything associated with the Ubuntu build and release process. Without Soyuz, Launchpad is just a dumping ground for source code.

https://launchpad.net/soyuz
"Soyuz is the distribution management portion of Launchpad. It encompasses the build system, package management and archive publishing.

Whenever you upload a package to Ubuntu, or need build information for that package, or download a package from the archive, you are using Soyuz. We also consider the mirror management and other distro-related portions of Launchpad to be part of the Soyuz subsystem. The word "Soyuz" means "union" in Russian, which is an appropriate name for the piece of Launchpad which integrates everything else to produce a distribution."

How committed is Shuttleworth to the idea that the open source process is the better process..when he's unwilling to open up the critical Launchpad component for the Ubuntu build and release processes for open development?

It could be argued that he's allowing the parts of Launchpad to be opened which have not succeeded as designed as a way to pull enough existing projects into Launchpad to make Lauchpad the center of gravity for work flow in the larger ecosystem. Rosetta for example as a translation component has received a significant amount of criticism from the existing Ubuntu translating community because it imposed on the translation community Canonical's idea of Launchpad centralization instead of upstream collaboration. Git has growing support outside of Launchpad itself compared to bzr. Is Canonical under pressure to improve its git compatibility as a launchpad service? Would Launchpad be a more compelling service offering if it had robust git access at this very moment?

-jef

[tm_anon]

They have to start somewhere. With Ubuntu set as a good frontman for Linux as a viable desktop OS, I'd suggest taking what they offer. Without Ubuntu, I never would've switched to Linux. There are lots of people who can say the very same and I would suggest that because of this ability it might just be a good idea to stop picking at it. Ubuntu is free, helps to nurture the true spirit of an OS which was built over time by the users, having pieces added to it as was needed rather than because it "might be cool" to the designers. Ubuntu doesn't charge for the OS, even from the CD it comes distributed on. It's very reliable and very easily set up, even providing a safe avenu for upgrades, expanding your library of programs and for learning about linux systems (ubuntu forums). It delivers on its promises to new users and is a great stepping stone into the world of Linux. I would honestly suggest that rather than picking at it until it falls apart, we help to nurture it. We need a good front man. We don't have to agree whole-heartedly with every move made by Ubuntu, but what are the alternatives? OpenSUSE drove my aunt AWAY from Linux, Red Hat scares more people than it invites, Fedora sounds uninviting. No, right now our best choice for a good front man is Ubuntu. The name is friendly, the message is clear and turning on your system for the first time with the drums really does help the user relax and realize this is going to be fun. Don't like the launchpad webpage? You're a linux user, create your own page, it's what we do.

[jspaleta]

Ubuntu != Canonical

Every single change I suggest of Canonical strengthens the Ubuntu "community's" ability to support itself and to do a better job of building a distribution. Soyuz is no different than Rosetta when it comes to empowering the Ubuntu community. Canonical's less than open leadership has been a continual frustration for the community who are contributing.

Canonical gets extremely good marks for talking friendly, for setting a tone of an inviting community. And I attribute that tone to Jono Bacon's deep passion for community building. Canonical's business motivation does not drive that tone. Nor does Shuttleworth's shallow commitment to the open source development process. Ubuntu is not built openly, and it won't be until Soyuz is openly developed.

I would invite you to look over the last 4 years of Ubuntu translation team communications concerning their frustration over the translations work flow as constrained by the toolset that Canonical requires them to use. Rosetta doesn't do the job, it frustrates the community of Ubuntu translators because it makes it duplicate the work that upstream project translators are doing and does not make it easy for the Ubuntu translators to submit the work back to upstream. These are real problem, real problem that the Ubuntu community of translators would be able to help solve in the context of the Launchpad service if Canonical empowered them to help build the tools to meet their specific workload need. Real problems that the Ubuntu translation community has been politely been trying to get Canonical to respond to for years...with no movement. If Canonical doesn't respond to that sort of friendly pressure to open up from its own community. So be it. I'm more than happy to play the heavy and publically pressure Canonical to open up and give those contributors the access they need to fix the tools and do the work they know they could be doing better. Rosetta is no different that Soyuz..access to the codebase makes it possible for contributors to do bettter work.

And its not just Rosetta. Canonical has/had a proprietary tool called MoM, which stopped working. External Ubuntu community rewrote it..and extended it as an open tool called DaD which can be argued the ubuntu contributors are actually happier with. The closed nature of MoM necessitated that Ubuntu community duplicate the effort of writing a tool. That's a problem. That's a problem with Canonical's corporate mindset about the unimportance of an open development model as part of contributor interaction with its own contributors. There is a problem is Canonical wants to continue to force people to use its proprietary tools to build Ubuntu by requiring them to use Soyuz. That is a problem for the Ubuntu community and for Ubuntu community interactions with upstream. I have absolutely no doubts that the Ubuntu contributing community would like have their contributions matter to upstream projects. But Canonical's workflow constraints around the tools that build the Ubuntu distribution make upstream collaboration outside of launchpad far more difficult than they could be. The answers to those problems are going to be found by opening those very same tools that build Ubuntu so that Ubuntu contributing members can adapt those tools. Canonical will not out think its own Ubuntu contributing community. If it doesn't understand that, then it doesn't understand the open source development process.

The Ubuntu community and the upstream projects themselves would benefit if every single piece of the toolset that the Ubuntu contributing community was asked to use to help build the distribution. And Canonical would benefit by being to build Launchpad that is more inline with what those contributors need. If Git really does have developer momentum, that is a problem for Canonical and launchpad if they only offer bzr.

This is the writing on the wall:
http://upsilon.cc/~zack/stuff/vcs-usage/

Git usage outside of launchpad..is on the rise and in Debian git based software is far outpacing bzr based development. And Ubuntu is based on Debian, Ubuntu merges a significant number of packages from debian. Since launchpad doesn't offer git support, launchpad will become a marginalized service offering as other service providers provide git based services to meet that growing demand. That's an important thing to consider moving forward...the momentum is clearly with git based upstream development. The sooner Canonical and Ubuntu community comes to terms with that trend, the better able they can as a community figure out how to extend Launchpad to offer git based services.

-jef

[mpt_nz]

(I work for Canonical but I am not speaking for them.)

Launchpad is a Canonical project, not an Ubuntu project, so referring to it as ?Ubuntu Launchpad? is rather misleading. Launchpad happily hosts thousands of software projects that have little or no involvement with Ubuntu.

With regard to Jef?s comment, those thousands of projects don?t use Soyuz either; they use the parts of Launchpad that are going to be open sourced. I?m sure the maintainers of Inkscape, Zope, Drizzle, and so on would be surprised to hear that the parts of Launchpad they use have somehow ?not succeeded?. Ubuntu?s translation policy, for example, has practically nothing to do with them.

[jspaleta]

Correction, ubuntu translation is launchpad translation. There is absolutely no difference. The translation policy for everyone working on translations in launchpad for Ubuntu or otherwise must agree to a common licensing policy for all launchpad projects.

https://help.launchpad.net/Translations/YourProject

The translation process in launchpad is designed to make it easier to share translations across projects inside Launchpad. It is not designed to make it easier to submit translations with upstream projects outside of launchpad. If inkscape and zope and drizzle and the rest of the projects in launchpad are not sharing translations..then yes that is a marked failure of the design of the translation component of Launchpad.

That sort of design decision is to the detriment of the Ubuntu distribution and makes it harder for the community of Ubuntu translators to see their contributions matter to the upstream projects where the development work is being done. That design decision was done in part to make Launchpad "important"
as a service by leveraging a network effect of a large pool of Ubuntu translators. If only launchpad hosted services benefit from that translation work, then more services will move to launchpad right? Except it has backfired more than its worked and the translation community Canonical has gathered as part of Ubuntu and to do translations in launchpad are frustrated by the limitations.

http://www.ogmaciel.com/?p=625

Read it, and read the entire set of comments.

What other design decisions were done specifically to generate a networking effect that leverage the Ubuntu community to bolster Canonical's Launchpad service offering? Hmm I wonder.

Correct me if I'm wrong but aren't how PPAs are built an offering that is part of the Soyuz component? But PPAs aren't made available for PPC or sparc, even though Ubuntu offers these arches as unofficially supported community ports. That sure sounds like a limitation in the design of the Soyuz component of launchpad that is directly impacting the ability of the Ubuntu community to support itself. If Soyuz were opened the Ubuntu community porting community could work on making it possible to have PPAs even if its not something Canonical has a vested interest in providing manpower for.

If you divorced Launchpad from Ubuntu and just had Launchpad be a service for individual projects..instead of selling it by leveraging the Ubuntu community networking effect to encourage people to host projects on its service.. a lot of problems just disappear. If Ubuntu's build and release process treated Launchpad hosted projects as peers with any other upstream projects the design problems would disappear.


-jef

[mpt_nz]

I think the only true sentence in that comment is ?The translation process in launchpad is designed to make it easier to share translations across projects inside Launchpad?. Everything else is false. Og Maciel?s claims are unfortunately literally years out of date, which isn?t surprising since he hasn?t used Launchpad Translations since about 2007. (For example, he falsely presented Launchpad Translations and Transifex as alternatives when they actually do quite different tasks.)