From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 246dc8c4 for ; Wed, 26 Jun 2019 15:12:25 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 576BC9BDE3; Thu, 27 Jun 2019 01:12:24 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 520AA9BC77; Thu, 27 Jun 2019 01:11:50 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 3A9A29BD84; Thu, 27 Jun 2019 01:11:48 +1000 (AEST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by minnie.tuhs.org (Postfix) with ESMTPS id 5451D9BC77 for ; Thu, 27 Jun 2019 01:11:47 +1000 (AEST) Received: from callcc.thunk.org (guestnat-104-133-0-109.corp.google.com [104.133.0.109] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5QFBhVo020457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 Jun 2019 11:11:44 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 25CCA42002B; Wed, 26 Jun 2019 11:11:43 -0400 (EDT) Date: Wed, 26 Jun 2019 11:11:43 -0400 From: "Theodore Ts'o" To: Larry McVoy Message-ID: <20190626151143.GC3116@mit.edu> References: <8D0B5B0D-9956-47D7-8D36-1729BB1E1DA9@eschatologist.net> <5df8c6f6-2768-4bfb-9c47-3345098078a7@PU1APC01FT048.eop-APC01.prod.protection.outlook.com> <20190625000630.GA7655@mcvoy.com> <20190625003120.GA28608@mit.edu> <20190625004523.GB7655@mcvoy.com> <20190626024503.GA43970@wopr> <20190626025646.GR925@mcvoy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190626025646.GR925@mcvoy.com> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [TUHS] CMU Mach sources? X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs@minnie.tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On Tue, Jun 25, 2019 at 07:56:46PM -0700, Larry McVoy wrote: > > It might not be, but it is definitely relevant to Unix. Arguably the > > drivers of Unix's development movement away from R&D-focused places and > > toward product-oriented entities had at least a little to do with > > Larry's topic of complaint. Product managers gained the ammunition to > > demand sustainable development practices, while R&D got a little leaner, > > a little more focused on demonstrating the thesis, a little less focused > > on who might need to run this code five years on... > > In the good old days at Sun, we were very focussed on who would run > this code for decades to come. I think the engineers at Sun were very > focussed on helping people, the reason we were there was because the > work we did helped people. The leverage was how much work we could > do versus how much that helped people. That is product oriented. > > I think the reason that any engineer works is because they feel like > their work helps someone. As an engineer, I wanted to go to the place > and do the work that had the best chance of helping someone. All of > Sun, when I was there, was like that. We were there to help. Yeah, > of course, we wanted to make money, but all of us wanted to help. > It's the dream, you do work, your work helps. Motivations and incentives are a very big and important aspect which is often overlooked in large scale projects. For example, one of the really big problems with device drivers in the embedded space is that the team that works on SOC version X gets disbanded, and immediately reassigned to SOC verison X+1, sometimes before product has even shipped. Having one device driver that works for SOC versions N, N+1, N+2, ... N+5, is really important from a maintainability and being able to send out bug fixes for security flaws. However, it means that whenever you make changes, you need to test on N different older versions. And between the need to release product quickly, and the fact that engineers are !@#@! expensive, and the teams constantly getting formed and reformed, it's much easier to do code reuse by copying, and so you have N different versions of a device driver in a Board Support Package version of the Linux kernel shipping by a SOC vendor. Unfortunately, I have to disagree with Larry, there are many, many engineers who works because they get a paycheck, and so they go home at 5pm. Some people might be free to improve their code on their own time, or late at night, but corporation also preach "work/life balance" --- and then don't fund time for making code long-term maintainable or reducing tech debt. Open source helps because embarassment can be a great motivator, but more important are the fact that there are people who are empowered to say "no" who don't work for the corporation who is trying to cut corners, and who have a higher allegiance to the codebase than their employer. There is a similar related issue around publishing papers to document great ideas. This takes time away from product development, and it used to be that Sun was really prolific at documenting their technical innovations at conferences like Usenix. Over time, the academic traditions started dying off, and managers who came from that tradition moved on, retired, or got promoted beyond the point where they could encourage engineers to do that work. And it wasn't just at Sun; I was working at IBM when IBM decided to take away the (de minimus) bonus for publishing papers at conferences. But at the Usenix board, I remember looking at a chart of the declining number of ATC papers coming from industry over time. And it was very depressing... And the key for all of this is motivation and incentives, as any good historian will tell you. This is true whether probing the start of wars, or the decline of a technical community or tradition. - Ted