You are touching a lot of topics in this comment. So I could only give very short answers to each of the points you touched. > Other than the possible revenue from keeping it proprietary, I don't consider the other excuses even applicable I do not think that per-seat licensing of the Launchpad code is a practical business model for Canonical. But I do not claim to know beforehand what all the revenue opportunities could be. A sensible entrepreneur avoids discarding possible unseen revenue streams unless there is a compelling reason to. > the memories of companies using the "fragmentation" card against free and open source software for years is still fresh, Java being among the latest to turn around. The way to avoid fragmentation is providing a way for community to participate, innovate and not using control. That is true for user-runnable software. And Canonical understands that very well as is demonstrated by the development processes of Ubuntu and Bazaar. Fragmentation, when talking about Launchpad, means something else: the value of Launchpad comes from the inter-relations between the numerous project communities that are using it. Multiple distinct Launchpad services would make interactions within any single instance total to less than it could be. More total users increase the value the project, lost opportunity decreases it. It is not a clear-cut issue. > Distributed services with open protocols is the long term sustainable approach. Centralized proprietary services just won't scale. This is a good point, and using a federated design was considered early on. This direction was not chosen to "keep the problem space simpler", as I said in the message you are replying to. Avoiding the additional complexity of a decentralized design was a good engineering decision in its own right. > The inherent problems of proprietary software is similar whether the software is running in the client or the server and in some ways more problematic given the rise of people and entities hiding behind software as a service to avoid facing the question. Let's agree to disagree. In my view, they are apples and oranges. > One symptom of the many problems with this approach is the workflow of translations not going to upstream by default and getting locked up into the distribution unlike transifex (http://transifex.org) which Fedora project seeded and follows the upstream by default model like the rest of the distribution in addition to being free and open source. Discussing the particular perceived shortcomings of Launchpad translations would distract us of what I regard as the main point of this thread, and I do not claim to understand this part of Launchpad well enough to address your concerns.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds