Re: top posting and flame
"Stephen J. Turnbull" <[email protected]>
| Newsgroups | gmane.comp.version-control.arch.user |
|---|---|
| Organization | The XEmacs Project |
| Message-ID | <[email protected]> |
>>>>> "Daniel" == Daniel Stone <[email protected]> writes: Daniel> Did Canonical somehow interrupt your work on GNU Arch? Do Daniel> you feel they are responsible for your not having been an Daniel> active Arch developer for well over a year now? If so, Daniel> can you please list how? Be specific. I hope you have better luck than I have had in getting an authoritative answer to those questions. I'd like to know the answers, too. To the best of my understanding, your questions have the wrong slant. Canonical didn't act to prevent Tom from doing what he wanted. Rather, they provided a sink for resources that would otherwise have flowed to GNU Arch. The story AIUI basically comes down to (1) Tom generously abdicated all claim to his legal monopoly over the Arch code base (Tom would probably prefer to scratch "generous" and simply call it the only ethical path, but you'll have to ask him). (2) Tom's excellent design and high levels of productivity ensured that no personal fork (eg, ArX) would attract harmful amounts of developer effort away from GNU Arch, despite the absence of any coercive monopoly. All is well with the world; the world gets an excellent free SCM in the short run, and Tom is free to pursue his long-run goals in and out of the GNU Arch project, with great prospects for more great stuff. The "satellite" developers conform to Tom's guidance since Tom's the only one who can manage the project. Financial contributions trickle in since Tom can and does fix bugs/add features to the extent that the changes are consonant with his vision for the project. (3) Canonical realizes that there is a short-term cost-reduction opportunity in using Arch, but they could get even more cost reduction for their specific short-run uses by changing the design in ways that Tom considered detrimental. They projected a sufficiently large benefit to this deviation that they were willing to pay something like 1-2 FTEs (my back-of-the-envelope estimate) to work on their branch. Those FTEs were spread over several developers, not all highly active in GNU Arch, but at least one large contributor was attracted to Canonical, as well as a former release engineer for Arch (but AIUI he was a volunteer for Canonical, too). (4) This provided a stable nucleus around which a number of Arch developers whose instincts aligned with the Canonical design more than GNU Arch's gathered, providing the necessary support for a commercial fork. (5) Negotiations to get Tom to work for Canonical fell through. I've not seen the details, maybe they were on the the developers' list. My conjecture is that Tom refused to work on the Canonical version without a promise of a substantial change of direction because he considered it wrongheaded and poorly coded, while Canonical was unwilling to pay for "whatever Tom happens to produce, it'll be great!" since that was unlikely to serve their short-term goals at all, and wasn't clear it would serve their medium-term objectives, either. (6) The fork is now established, and contributors start to choose their primary allegiance. This time the fork has robust prospects, so the level of interest in GNU Arch falls perceptibly, reducing both code and money contributions to the mainline. Financial distress forces Tom to reduce work on Arch, etc, at a time when other resources for the project are also being reduced. So the issue is not that *Tom* was "prevented" from working on Arch; it's that the GNU Arch project would have done great things, requiring only general guidance and occasional direct effort from Tom, had it not been starved of resources by the presence of the "false SCM" baz. In the meantime, Tom could continue work on other pieces of the grand puzzle. It's the same story with any fork. By the nature of a fork, the projects are similar and will compete for the same resources. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.