Re: My new job - Mailing list pgsql-hackers
From | Ross J. Reedstrom |
---|---|
Subject | Re: My new job |
Date | |
Msg-id | 20001013120028.D3935@rice.edu Whole thread Raw |
In response to | Re: My new job (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: [GENERAL] Re: My new job
|
List | pgsql-hackers |
On Tue, Oct 10, 2000 at 01:02:52PM -0400, Tom Lane wrote: > > Bottom line is we're not sure what to do now. Opinions from the > floor, anyone? > First, I include my voice with those congratulating Bruce, and wishing him the best of luck in his new position. I concur that no one who has paid any attention at all to how the core developers interact with the user base on the mailing lists can have any thing but the highest regard for all of your integrity and devotion to the project. Given that, there is little fear of overt actions by Great Bridge that could harm the project, short of firing you all and leaving you destitute on the street (which wouldn't last long, I'm sure ;-) As I mentioned in thread that followed Ned Lilly's first post here, the real threat to code quality will be management pressures, such as schedule pressure: when Management wants a new release so that Marketing can better sell against a competitor with a higher release number, what do you do? There are a dozen scenarios I could spin, each more fantastic than the last, but all grounded in someones real world experience. All the core members have more experience than I in the world of corporate coding, so can probably spin worse ones. How each of you handles those kind of pressures is up to your own internal compass: just let me remind you that, unlike most situtations where the individual is alone, the user community here can be a _personal_ resource, standing up for you, and providing an outside voice, if needed. Enough with worst case scenarios. As you said, Tom, the real problem is about the preception of the community. How to avoid misunderstandings? I think Peter's point about transparency of development _process_ is crucial. As it is, there have been in the past occasional back channel communications where design decisions get made, via IRC or phone calls. This in and of itself is not a problem: some problems are just easier to thrash out that way. The problem comes when the decision is presented as a fait accompli, without a clear public statement of the reasoning behind the decision. Sometimes it's easy to forget if a particular point got made on te phone, in a public email list, or a private, core list. This could easily spin out of control, if decisions get made over the water cooler, as it were. To date, the core developers have served as steering committee, as well. This is only natural on an all volunteer project: in that case, no one can order anyone to do anything they don't want to, so only the developers can direct the project. The Debian project runs into this all the time: Herding kittens, it's called. ;-) Now, the problem is that it is perceived that some one _can_ order the developers: analogous to the criticisms of electing John Kennedy as U.S. President, since he was Catholic, and therefore preceived to be under the Pope's control. That's, of course, extreme, but Tom himself has said that'd he'd work on bug fixes for paying customers over mailing list submissions. That's his right, and no different than a volunteer developer deciding that work or school assignments take precedence. It's happened to me, enough. But it's the perception that matter here, not the fact. What to do? Make as much communication as possible public. When in doubt, err on the public side. Develop in the fish bowl. If you feel there still a need for private channels, perhaps include some outside representitive, trusted by the community, who can serve as a witness of record, if you will, vouching for the intent of the communications, without having to reveal the content. Well, there's my nickel. Do with it what you will. Ross Ross J. Reedstrom, <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005 -- Open source code is like a natural resource, it's the result of providing food and sunshine to programmers, and then staying out of their way. [...] [It] is not going away because it has utility for both the developers and users independent of economic motivations. Jim Flynn, Sunnyvale, Calif.
pgsql-hackers by date: