Linden Lands and Open source

First i must admit that I'm still pretty new in the open source community around linden labs. However I have been around open source environments for like my hole computer life starting at University. I have also been working in commercial companies, like Ericsson, since 1998. There are big culture differences between the two. In some parts this is now clashing hard to the surface. The open source developers starts to feel frustrated that the LL don't care about them. the LL getting frustrated that the open source community is so open and frank in there communication.

This culture clash comes really to the surface in a flame war between Bryan (Linden) and Alissa, about the move to cmake. Here Linden labs does what is common in a cooperate world. They share a little informations about what they are doing. How the progress is going and so forth. Alissa coming form a more open source world, is more direct in her words of why she don't see the need to wait with giving out all the needed info, e.g. the code. Bryans answer now show just how big the culture clash is at the moment. And even more so in the following message. Then Rob Linden come in and shares some information that probably is a severe and strange to the open source comunity as it is unavoidable in how LL works there company.

This is also probably the reason why i can't get windlight builds to work. Linden labs have made a clean out off stuff that they don't release. There internal source structure is different and there own. Releasing code, and releasing a viewer is a painful process. My releasing is to hard, i think:

$ scons -j4 DISTCC=no BTARGET=client OPENSOURCE=no BUILD=releasefordownload CHANNEL=Release MOZLIB=YES
$ diff -Naur -x '*tar.bz2' -x .sconsign.dblite -x packaged -x '*.o' -x '*.a' -x '*.pyc' -x '*.so' -x '*sln' -x '*-bin*' -x '*.swp' -x build -x '*vcproj' 18.5.3.linden 18.3.5  > balp-build-u2.diff
$ grep ^+++ balp-build-u2.diff |less
$ scp balp-build-u2.diff.gz 18.5.3/indra/balp-build-u2.tar.bz2 shaka.acc.umu.se:public_html/second_life/

Then make a blog entry about it and hope it helps someone. In all commercial projects i have worked at, I can't stay at that level. It's to much work. For source code it can not be harder that merging and checking in and applying a label. Any code clean up for release tells me I'm working the wrong way. My favorite way are checking in, label and send a mail to a college asking him, her to merge it. That way we get a code review, and make sure that someone else have understood the code. When i merge code, I also make the the release build, e.g. after making the code merge, just type "merge release" and maybe in a hard world add a label to that. There should be no more interaction form me them more build would have errors in them. Errors that could have been avoided.