User: Password:
Subscribe / Log in / New account

Ubuntu, security response, and community contributions

Ubuntu, security response, and community contributions

Posted Jul 23, 2008 19:47 UTC (Wed) by ddaa (guest, #5338)
In reply to: Ubuntu, security response, and community contributions by rahulsundaram
Parent article: Ubuntu, security response, and community contributions

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

(Log in to post comments)

Ubuntu, security response, and community contributions

Posted Jul 24, 2008 2:20 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

You said Canonical employees disagreed with opening the source code and giving access to the
community inorder to retain potential revenue opportunities. I merely conceded that is a
understandable excuse (though I disagree completely with the decision to keep it proprietary).
I don't know why you even bought up "per-seat licensing". Sensible people working within a
community would want to gain trust by not acting inconsistently or giving outlandishly false
claims (c.f security history) whether they are entrepreneurs or not. Anything else is just
short sighted and not even within their self interest. 

Multiple distinct instances need not ever decrease the value of the service at all. It depends
on how well you federate it. Sure, it is more complex but that is price you need to pay for
working with a distributed community of producers and consumers. In my view, the workflow of
translations is a clear direct result of a deliberate strategy to keep the content within the
distribution essentially closed within itself instead of helping the broader upstream
community. The problem is well known and has never been addressed so far. This combined with
the decision to keep the source code closed doesn't indicate or inspire good faith. 

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds