| |||||||||||||
No Mir by default in Ubuntu 13.10No Mir by default in Ubuntu 13.10Posted Oct 3, 2013 11:05 UTC (Thu) by khim (subscriber, #9252)In reply to: No Mir by default in Ubuntu 13.10 by k8to Parent article: No Mir by default in Ubuntu 13.10
That's why we have dozens of Linux phones projects which were developed by “community” and failed plus one “developed in isolation” which succeeded. Paint me unimpressed. I have my doubts about Mir, but they are related not to the fact that it's developed in isolation but to the fact that it's developed by a small company which does not have the ability to actively promote the end result, push large companies around, etc.
(Log in to post comments)
No Mir by default in Ubuntu 13.10 Posted Oct 3, 2013 11:40 UTC (Thu) by ovitters (subscriber, #27950) [Link]
I share your opinion. I want open source / free software companies to succeed (all of them!). No matter if that is Google where you can argue if Android is free software, or just any other company. For Canonical, I think they're not big enough to work isolated and this might cause a failure. My criticism is because I want them to succeed and I think there are things they could work on. At the moment only Google seems to have success (talking solely about Android). Copying another company is not enough, should figure out why they're a success.
No Mir by default in Ubuntu 13.10 Posted Oct 3, 2013 12:01 UTC (Thu) by robclark (subscriber, #74945) [Link]
I think you may find that the success of android is a result of factors other than the development model.
No Mir by default in Ubuntu 13.10 Posted Oct 3, 2013 17:14 UTC (Thu) by khim (subscriber, #9252) [Link] May be. But this goes against Occam's razor principle. Android have won because it was there first. In “good enough” state, I mean. OpenMoko, Maemo/Meego, Tizen and many other projects have failed for one simple reason: they were late. And it's obvious that “proper” “community project” moves slower then “developed in isolation” project. Simply because you need more interactions to achieve consensus. Of course at later stage (when basic functionality is done) you need “community” (or at least “alliance”) because it's the only way to create lots of small tweaks, but start doing that too early and your project will not be done in time.
No Mir by default in Ubuntu 13.10 Posted Oct 3, 2013 17:25 UTC (Thu) by robclark (subscriber, #74945) [Link]
android won because it had the corporate credibility with carriers and handset manufactures which comes from the google backing. That is really all.
No Mir by default in Ubuntu 13.10 Posted Oct 3, 2013 20:27 UTC (Thu) by khim (subscriber, #9252) [Link] Really all? Why Google (an outsider company!) could do that but Nokia (with Meego), Motorola (with OpenEZX), Samsung (with SLP) and even dozen of high-profile mobile companies together (with LiMo) could not do that? Yes, “corporate credibility” is important (and Ubuntu is sorely lacking in this department), but something else is clearly needed, too.
No Mir by default in Ubuntu 13.10 Posted Oct 3, 2013 21:18 UTC (Thu) by robclark (subscriber, #74945) [Link]
yes.. well, I actually worked for an SoC vendor at the time android was starting, so maybe had a bit of a different perspective. But seems to me like their success was:
(a) somewhat neutral ground (ie. not associated with one or small # of handset makers or carriers), with a big enough backer that all the carriers and handset makers pay attention (b) get something out there... doesn't matter that it really sucks in the beginning, google is big enough to catch developer interest to start getting app ecosystem going (c) rinse, repeat until you have something decent
But don't underestimate the google power.. a lot of people inside the industry were pretty much assuming android would be the next big thing back when android was in diapers and way inferior on a technical level compared to alternatives like maemo/meego.
No Mir by default in Ubuntu 13.10 Posted Oct 4, 2013 9:19 UTC (Fri) by BlueLightning (subscriber, #38978) [Link]
Er, did Motorola actually sponsor OpenEZX or was it simply a community project?
No Mir by default in Ubuntu 13.10 Posted Oct 4, 2013 16:22 UTC (Fri) by khim (subscriber, #9252) [Link] Mea culpa. Of course Motorola's project was called EZX. You are right, OpenEZX is community project not supported by Motorola.
No Mir by default in Ubuntu 13.10 Posted Oct 3, 2013 17:47 UTC (Thu) by k8to (subscriber, #15413) [Link]
Google has pretty much no real concern whether Android gets broader uptake in the wider Linux development world. And they haven't gotten it.
You can call it successful anyway, but that's not the kind I meant.
No Mir by default in Ubuntu 13.10 Posted Oct 3, 2013 21:31 UTC (Thu) by khim (subscriber, #9252) [Link] Google has pretty much no real concern whether Android gets broader uptake in the wider Linux development world. It does, it does. And it gets said uptake. E.g., there used to be pretty diverse and wild world of embedded systems - yet today Android is there and it's slowly crushing incumbents. When you have large enough ecosystem developers will come—like kernel developers did. The one thing Google does not do is playing favorites: “uptake in the wider Linux development world” is important but of course “uptake in the wider gamedev development world” is important too and “uptake in the wider mobile apps development world” is even more important. Not because Google hates “the wider Linux development world” but because “the wider Linux development world” is actually smaller than “gamedev development world” and much smaller than “mobile apps development world”. You can call it successful anyway, but that's not the kind I meant. Why not? What kind of “success” you've meant? I'm not jeering at you, that's a honest question. Usually success of a given endeavour is measured in monetary terms, but it's pretty poor measure for open source platforms thus I tend to think more in terms of “number of users” or may be more of a “percentage of users” (not many users use Linux on supercomputers, but it's still a success since most users who do anything with supercomputers at all do that with Linux nowadays). If you don't like that criteria then offer your own… with explanation for why do you think this must be measure of success.
No Mir by default in Ubuntu 13.10 Posted Oct 6, 2013 11:51 UTC (Sun) by krake (subscriber, #55996) [Link]
> That's why we have dozens of Linux phones projects which were developed by “community” and failed
Dozends? OpenMoko and?
> plus one “developed in isolation” which succeeded
plus a couple that were not community developed and failed, e.g. Maemo, WebOS
No Mir by default in Ubuntu 13.10 Posted Oct 6, 2013 12:17 UTC (Sun) by khim (subscriber, #9252) [Link] Dozends? OpenMoko and? GPE, OPIE, Enlightenment and many, many others. Very few reached the stage where you can actually use them on the real hardware (OpenMoko is rare success by the standards of phone projects developed by “community”), most died before reaching that stage. plus a couple that were not community developed and failed, e.g. Maemo, WebOS These are developed by “community” nowadays, too. As Mer and Open webOS. These, too, have about the same level of success as all other “community” projects.
No Mir by default in Ubuntu 13.10 Posted Oct 6, 2013 13:04 UTC (Sun) by krake (subscriber, #55996) [Link]
> GPE, OPIE, Enlightenment and many, many others.
Ah, good to know. Didn't know about the first two and I thought Enlightenment was a desktop software project.
> Very few reached the stage where you can actually use them on the real hardware
I am not sure I can follow here. Either they shipped and failed or they were simply not used. Failure implies trying.
> These are developed by “community” nowadays, too.
Maybe, didn't followed them too closely. Doesn't change the fact that they failed while not being community developed.
There is no correlation and certainly no causation between single vendor vs. multivendor developed product and market success.
What we can probably correlate is knowledge about number of prototype iterations with development process transparency.
No Mir by default in Ubuntu 13.10 Posted Oct 6, 2013 13:51 UTC (Sun) by khim (subscriber, #9252) [Link] I am not sure I can follow here. Either they shipped and failed or they were simply not used. Failure implies trying. Of course they have tried! They have some code, bunch of repos, even some demos. Best case scenario: they managed to run their stuff on a couple of old smartphone models (usually with bunch of hardware non-functional). OpenMoko is in this camp, the only thing which places it in their own category is the fact that it had software developed and actually created specifically for OpenMoko. Maybe, didn't followed them too closely. Doesn't change the fact that they failed while not being community developed. Well, if “community” is so important then what can't it make these projects success? Are projects which were adopted by community are somehow more problematic then projects developed by “community” from the start? What we can probably correlate is knowledge about number of prototype iterations with development process transparency. Hmm... So by now we know that opaque approach succeeds from time to time (even most iPhone suppliers had no idea that Apple does iPhone, Android developed Gerrit to make sure different developers can't see each other work yet still can develop common components, etc), while transparent approach fails (all “transparent” efforts are faileres. What does it say about “community” chances?
No Mir by default in Ubuntu 13.10 Posted Oct 6, 2013 14:20 UTC (Sun) by robclark (subscriber, #74945) [Link]
> Android developed Gerrit to make sure different developers can't see each other work yet still can develop common components
a bit off topic, but that would explain why I find gerrit so aggravating to use. Is that really true? Do you have a reference for that?
-----
back on the main topic.. I think the short answer is success or failure of a phone ecosystem has more to do with other factors than development model. But the fact that there are so few successes makes it difficult to draw any sort of conclusion.
No Mir by default in Ubuntu 13.10 Posted Oct 6, 2013 14:45 UTC (Sun) by khim (subscriber, #9252) [Link] What kind of “reference” do you need??? It's not a secret that enforceable access control was the reason for the Gerrit creation. Of course later it have gotten other properties, too, but initially it was just a “Rietvield with access control”. Heck, it's in description of the project background: Gerrit Code Review started as a simple set of patches to Rietveld, and was originally built to service AOSP. This quickly turned into a fork as we added access control features that Guido van Rossum did not want to see complicating the Rietveld code base.
No Mir by default in Ubuntu 13.10 Posted Oct 6, 2013 15:31 UTC (Sun) by robclark (subscriber, #74945) [Link]
> What kind of “reference” do you need??? It's not a secret that enforceable access control was the reason for the Gerrit creation. Of course later it have gotten other properties, too, but initially it was just a “Rietvield with access control”. Heck, it's in description of the project background: Gerrit Code Review started as a simple set of patches to Rietveld, and was originally built to service AOSP. This quickly turned into a fork as we added access control features that Guido van Rossum did not want to see complicating the Rietveld code base.
well, write-access control to prevent a developer from 'git push origin bonghits' is different from read-access, ie "developers can't see each other work". I was curious if read-access was actually a motivation as you at least seem to have implied. I didn't get this impression from either the wikipedia article or the 'project background' link.
one of my long standing complaints about the gerrit workflow (vs, send-patches-to-public-list approach, possibly augmented w/ patchwork) is that by default only the people you choose to review some patch(s) get notified. Vs. everyone seeing the patches and having a chance to review/comment.
No Mir by default in Ubuntu 13.10 Posted Oct 6, 2013 16:08 UTC (Sun) by khim (subscriber, #9252) [Link] well, write-access control to prevent a developer from 'git push origin bonghits' is different from read-access, ie "developers can't see each other work".Well, yeah. One is relevant to Rietveld, another is not relevant. I didn't get this impression from either the wikipedia article or the 'project background' link.Really? Please read it again. This quickly turned into a fork as we added access control features that Guido van Rossum did not want to see complicating the Rietveld code base. Then again. …access control features … Rietveld … code base. Got that? NOOO? I'll explain. Just what is Rietveld? It's collaborative code review tool. It can not read code from subversion or git (this is work of depot_tools), it can not commit code to the repo (this is work of commit queue), it's strictly and specifically review tool. Heck it's not even involved in ownership decisions—this is work for the presubmit scripts. Any changes which are complicating the Rietveld code base by necessity must affect patch review process—because Rietveld does not do anything else. Just what kind access control for patch review process can you imagine which does not affect patches viewability status? No, really? You may forbid certain users from adding the comments, but this change is pretty localized: you only need to check these things when new comments are added. You may add OWNERS, but this change does not affect Rietvield at all (it's enforced by presubmit scripts and commit queue). The only kind of change which may significantly perturb Rietvield's codebase is pervasive access control which determines who and when can watch patches which are in process of review. This will be invasive: this will mean that you need huge amount of checks spread over the codebase. All the information needed is there (and always was there), you just refused to connect the dots. one of my long standing complaints about the gerrit workflow (vs, send-patches-to-public-list approach, possibly augmented w/ patchwork) is that by default only the people you choose to review some patch(s) get notified. That's the whole point of gerrit! It's raison d’être! It's designed to facilitate parallel development of “open source” Android's code and vendor's proprietary “secret sauce” in parallel thus such decision makes perfect sense. Vs. everyone seeing the patches and having a chance to review/comment. Oh yeah. Imagine that. What SAMSUNG will do if patches needed to support their next innovative “air scrolling” will be seen by HTC or SONY? This will be huge brawl. Not pretty at all. This is what gerrit is dealing with: companies who actively try to destroy each other—yet are forced to cooperate. “Everyone seeing the patches and having a chance to review/comment” does not work for that.
No Mir by default in Ubuntu 13.10 Posted Oct 6, 2013 18:42 UTC (Sun) by robclark (subscriber, #74945) [Link]
> All the information needed is there (and always was there), you just refused to connect the dots.
Well, I guess I'm just not reading between the lines as hard as you are. I was looking for something a bit more concrete and a bit less conspiracy-theory.
All the same, my opinion remains the same: it isn't really a terribly good process tool for open source projects.
|
|||||||||||||