开源日志：Linus Torvalds’s Lessons on Software Development Management

网上找到了linus的访谈，但是翻译过来的明显是机器翻译，所以我尽力而为的翻译。

Linus Torvalds’s Lessons on Software Development Management

    If anyone knows the joys and sorrows of managing software development projects, it would be Linus Torvalds, creator of the world's most popular open-source software program: the Linux operating system. For more than 20 years, Torvalds has been directing thousands of developers to improve the open source OS. He and I sat down to talk about effective techniques in running large-scale distributed programming teams – and the things that don’t work, too.
    Torvalds says there are two things that people very commonly get completely wrong, both at an individual developer level and at companies.
    “The first thing is thinking that you can throw things out there and ask people to help,” when it comes to open-source software development, he says. “That's not how it works. You make it public, and then you assume that you'll have to do all the work, and ask people to come up with suggestions of what you should do, not what they should do. Maybe they'll start helping eventually, but you should start off with the assumption that you're going to be the one maintaining it and ready to do all the work.”
    Torvalds continues, “If you start off with some ‘kumba-ya feeling’ where you think people from all the world are going to come together to make a better world by working together on your project, you probably won't be going very far.”
    “The other thing—and it's kind of related—that people seem to get wrong is to think that the code they write is what matters,” says Torvalds. Most software development managers have seen this one. “No, even if you wrote 100% of the code, and even if you are the best programmer in the world and will never need any help with the project at all, the thing that really matters is the users of the code. The code itself is unimportant; the project is only as useful as people actually find it.”
    I'll add at this point that this isn't just a programmer problem. I've seen entire companies get locked into the idea that “perfecting” the program was everything. They then neglected what the users wanted from the program, supporting the users and so on. Most of us who've been in the business for a while have seen this cycle play out over and over again.
    Expanding on that second point, Torvalds says that's why the Linux kernel team is “so very anal about the whole ‘no regressions’ thing, for example. Breaking the user experience in order to ‘fix’ something is a totally broken concept; you cannot do it. If you break the user experience, you may feel that you have ‘fixed’ something in the code, but if you fixed it by breaking the user, you just violated that second point; you thought the code was more important than the user. Which is not true.”
    Torvalds concludes, “Way too many projects seem to think that the code is more important than the user, and they break things left and right, and they don't apologize for it, because they feel that they are ‘fixing’ the code and doing the right thing.”
    To that I can only add “Amen!”

    On the Importance of Development Tools

    I also asked Torvalds about Software Configuration Management (SCM) tools like his own Git version control system. He replied, “I don't think tools are all that fundamentally  important.”
    “Now, what is important is that there's a good workflow for the project, and tools can certainly help with that,” said Torvalds. “But most projects don't necessarily really need tools. There's a lot of projects that simply don't have enough changes to really require any tools at all for their work flow; if you only have a few hundred patches per release, you can maintain those just about any way you want, including entirely by hand.”
    Linux is a different story of course. “For the kernel, we have thousands of patches flying around every release, and a release roughly every three months, and so for us the tools really are very important,” he says. “But I still don't think it was all that big a mistake to just do tar-balls and patches for the first few years of development; it was a much smaller project back then, and it took several years for the lack of tools to really become a problem.”
    Besides, “Some tools encourage workflows that are actively detrimental, and I think CVS [Concurrent Versions System, a version control system] for example has caused a lot of projects to have the notion of a 'commit cabal,'” Torvalds continues. “I personally tend to think tar-balls and patches are actually preferable to that – if only because they make all developers 'equal,' and you don't get the kind of model where certain people have 'commit access,' and the rest are second-class citizens. Sometimes it's better that everybody is a second class citizen than that some people have an easier time at it.”
    Torvalds, I should note, knows CVS well and has hated it for years. As he said in a Google Talk in 2007, “I hate CVS with a passion.”
    Torvalds continues, “Much more important than the tools is the people. The maintainers, and the mindset.”

    Keeping People On Track

    And how do these people work together today? I asked Torvalds about the role of the Linux Kernel Mailing List (LKML) in the process. He replied, “I think Linux used to ‘happen’ more on LKML than it does these days. The signal-to-noise ratio and just the pure volume of LKML means that most developers simply don't have time to really read LKML—at best they scan subject lines. As a result, these days I'd argue that most of the real development happens within the sandbox of single developers, and then email on more of a person-to-person scale is actually how things really get done.”
    That said, “That doesn't mean that LKML isn't important; it means that LKML has become the ‘public band’ of all those individual email threads,” Torvalds adds. “So what ends up happening is that you have maybe four or five people involved in a discussion about their work, but LKML stays cc'd on the whole thing. That turns what would otherwise be a purely private discussion into something where others can jump in.”
    Here's how it works, “A lot of people actually don't really ‘read LKML;’ they often auto-archive it, but then react to certain keywords or, more often, [to] key people being involved in the discussion.”
    “It also acts as a kind of archiving notion,” Torvalds continues, “so that people can refer to it later, and a lot of bug reports end up being found by Googling for them. If somebody raises an issue, it may well be some odd hardware problem, but if Google shows that it's been raised several times on LKML in the past, that starts to indicate that it may be obscure, but it's certainly not some totally isolated issue.”
    “So I think LKML is really quite important, but no, it's not how we keep people ‘on track,’” he says. “All the developers tend to be pretty self-motivating, and they all have sane ideas (well, the core ones do by definition – because that's how they became core developers, by showing that they had good taste and high motivation). It's important simply because that ‘public part’ of the discussions are still important, even if in practice it's often a pretty small core in any particular discussion. Things are simply different when they happen in the open,” concludes Torvalds.

    On Delegating – and Staying Sane

    Once, Linux was a solo project. It now has thousands of committers and contributors. I then asked, “How much delegating do you these days? Any thoughts on how to delegate to keep one's sanity and the workflow flowing?”
    “If there's one thing I've learnt, it is that you have to learn to let go and not try to control people and the code,” he says. “If you don't think somebody else can do it on their own without your oversight, you might as well give up immediately as a maintainer.”
    He continues, “Yes, I often get involved in small details, but it's not because I don't trust people or don't delegate. It's because some small detail ends up being brought up to me. Either it's a bug (and they are almost all just silly small details that got overlooked), or it's just some workflow issue that bothers me (like me complaining about the developer names not showing up properly in the logs earlier today to one sub-maintainer).”
    Still, says Torvalds, “Those details have to be occasional details, not the kind of ‘look over the shoulder of the developer to check everything he does.’ I trust sub-maintainers to do the right thing 99% of the time. And then, very occasionally, I end up complaining loudly about something.” Say, for example, on how the open-source GNOME desktop is, or rather isn't, moving forward.

    So, there you have it. That's some of the ways Torvalds does it. And, if you think you know better, ask yourself: Have I created a world-class operating system that runs most supercomputers, stock-exchanges, and websites like Google? If your answer's no, I'd re-read his answers and take a long hard think about how you've been managing your own projects.

译文如下：

访谈：Linus Torvalds谈软件管理

    软件工程管理充满了欢乐和辛酸，没有谁比Linus Torvalds更有感触的了，他是世界最流行的开源操作系统linux之父。在过去的20多年里，Torvalds指导了成千上万个开发者参与和改进linux。他现在和我做下来讨论关于管理大型分布式开发团队的经验，以及那些陷阱和误区。

    Torvalds说有两个想法完全是错误的，从独立开发者到公司都有这个问题。

    “第一个想法是，我们能把一个项目扔在那里，然后让别人帮忙去完成。”他说，“这完全行不通，开源项目也不是这样运作的。你把项目开源，然后假设你要自己完成所有的工作，然后让别人来建议你应该如何做——而不是交给别人，让别人想应该怎么做。也有可能偶尔会有人主动参与，但你必须假设你是唯一一个留下来完成这个项目，并时刻准备着独立完成它”。

    Torvalds继续说，“如果你一开始就想做一个伟大的项目，并且想着世界上所有的开发者都会来参与这个项目，这个项目可能会很快就死掉”。

    “第二个想法是，和第一个相关，人们总觉得产品的成败决定于代码”，Torvalds说，“所有的软件管理者都看到了这一点。实际上并不是，即使所有代码都是你写的，即使你是世界上最好的天才程序员，最大的问题也不是代码bug，而是满足产品用户的需求。代码本身并不是最重要的，代码的价值是从人们开始使用它的产品时开始的。”

    “所以我想重点说明的是，不是所有的问题都是程序员的问题。你会看到很多公司进入了一个怪圈，他们认为研发一个“完美”（没有bug，高性能，高效率，高稳定性，高可用性）的产品就能解决一切问题。他们忽视了用户想通过产品得到什么，忽视服务和售后支持用户等等。我们这些“老人”看到这个怪圈在软件行业不断的上演，一直未停。”

    扩展一下第二个问题，Torvalds说这就是为什么linux内核小组“非常审慎，例如，绝对不允许为了解决一些问题而破坏了用户体验，你不能这么做。如果你破坏了用户体验，你可能觉得你解决了代码的一些问题，但如果你用损害用户利益的方法来解决代码问题，你就是第二个错误的想法——你觉得代码比用户都重要，但这不是事实。”

    Torvalds总结道，“很多项目认为代码比用户重要，所以他们整天东搞搞西搞搞，这里改改那里改改，让用户不知所措却从来不道歉，因为他们觉得他们正在解决代码的问题，在做‘正确的事情’”。 那我只能对他们说“阿门”。

关于开发工具的重要性

【译注：先省略关于CVS等的探讨，现在linux是用git管理代码的】

    Torvalds继续说“比工具重要得多的是人：维护者和心态”。

【译注：其他的部分先不译了，我关心的就这些。】

【winlin译注：

同意Torvalds所指出的两个问题，第一个实际上是软件产品并不能被简单分解，《人月神话》实际上说的就是这个事情。《人月神话》是IBM360之父，预言“没有银弹”的那个科学家，指出程序并没有多大价值，程序必须被产品化（满足需求/性能/稳定性/缺陷限制/测试/文档）和系统化（产品对接/集群/对接）；从程序到产品/系统，不是单纯的加入能解决问题，软件不能被简单的分解。这个说的实际上是大规模复杂软件管理者应具备的素质。

第二个问题说的是目标问题，很多项目的目标不是为用户服务而是创造代码，我想首先是没有这种观念，另外是一般公司研发出来的都不是“完美”产品，导致陷入恶性循环拖累了整个研发团队。所以我觉得torvalds的这个观点不能简单的理解为“功能第一，发布充满了bug的产品吧”，研发团队必须要产出高质量的软件，到了这个水平之后呢？难道高质量的软件就一定达到目标被用户所认可？这个就是Torvalds说的第二个问题了。这个说的实际上是超越软件编码的使命。

研发优良架构的高质量的软件产品和系统是软件工程师的份内之事，而熟悉软件管理研发复杂大规模系统，以及以用户为中心的终极目标，是一个伟大软件工程师的使命。

】