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
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.