[linux-elitists] rambleling about windows source code
Tue Feb 17 15:54:51 PST 2004
On 17 Feb 2004, Ben Woodard <firstname.lastname@example.org> wrote:
> On Sat, 2004-02-14 at 15:33, Martin Pool wrote:
> > I don't think they could quite come at the GNU GPL. I think the Sun
> > Java shmozzle has shown that for licensing, near enough to free is not
> > good enough. So perhaps they will try this, but it will flop. On top
> > of this, there are the technical issues of outside developers trying
> > to come to grips with 30GB (really?) of source. Mozilla and
> > OpenOffice are nothing by comparison.
> Knowing how this works in the linux world. I don't think that this is
> really a problem. You learn the bits and pieces that are of interest to
> you and ignore the rest. For example, right now I do kernel programming.
> Does this mean I know the whole kernel -- no. I know the ia64 MCA
> handling code really well, plus a couple of drives and then have an
> overview of how certain other parts work.
OK, I was exaggerating about requiring the whole 30GB. But your
experience with Linux is not necessarily a good guide. Of necessity,
open projects tend to be easier to build and deal with separately,
because random people want to do it.
It's easy for in-house projects to make assumptions about, say, being
built in C:\build, or having the whole project's source tree installed
somewhere to find headers, or that making a real binary distribution
requires special tools that only the QA group can run. You can even
(weakly) defend those requirements as making builds reproducible, or
easy to debug, or preventing programmers slipping un-blessed code out.
So perhaps you'd need, say, the kernel source installed to be able to
build GDI. There are all kinds of forces towards making in-house
projects tricky to build, and no real reason to resist them.
Those assumptions can be pretty hard to tease out if you ever want to
let people outside the core team use your source.
See, for example, comments from Microsoft people in the Halloween
> o Different development "modes".
> Setting up an NT build/development environment is
> extremely complex & wildly different from the environment used by the
> Office team.
> o Different tools / source code managers.
> Some teams use SLM, other use VSS. Different bug
> databases. Different build processes.
(Ha ha VSS)
> o No central repository/code access.
> There is no central set of servers to find, install,
> review the code from projects outside your immediate scope. Even
> simply providing a central repository for debug symbols would be a
> huge improvement. NatBro:
> "a developer at Microsoft working on the OS can't scratch an itch
> they've got with Excel, neither can the Excel developer scratch their
> itch with the OS -- it would take them months to figure out how to
> build & debug & install, and they probably couldn't get proper source
> access anyway"
> o More component robustness
> . Linux and other OSS projects make it easy for developers
> to experiment with small components in the system without introducing
> regressions in other components: DavidDs:
> "People have to work on their parts independent of the rest so
> internal abstractions between components are well documented and well
> exposed/exported as well as being more robust because they have no
> idea how they are going to be called. The linux development system has
> evolved into allowing more devs to party on it without causing huge
> numbers of integration issues because robustness is present at every
> level. This is great, long term, for overall stability and it
Doing the cleanup work to make code releasable might (ceteris paribus)
make development easier for in-house hackers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20040218/b980d5ae/attachment.pgp
More information about the linux-elitists