On Sun, Mar 14, 2010 at 6:23 AM, Maggie Leber (sl: Maggie Darwin) <mag...@matrisync.com> wrote: > On Fri, Mar 12, 2010 at 3:31 PM, Soft Linden <s...@lindenlab.com> wrote: > > If Linden Research continues to project the attitude that open-source > is no more than a convenient way to get some free grunt labor from > "enthusiasts" (which strikes me as code for the "hobbyist" term > Microsoft likes to use to veil their contempt when they want to > deprecate open-source folks as unprofessional), while locking them out > of strategic discussions and decisions about the project's direction, > this effort is doomed to the "throttling" your scolding referred to.
You're putting a term in quotes when you're the one who introduced it to the discussion. You're then picking apart another party at length for your selection of words. > It's neither far-fetched nor paranoid to think that Linden Research > would like nothing better than to see the viewer devolve into a > balkanized forest of incompatible versions and forks, struggling to > catch up to capabilities designed and built in secret I'd love to be proven wrong, but I expect we'll remain the biggest contributor for some time. So yes - others will be struggling to catch up at times. It does us no good whatsoever to encourage incompatible versions and forks, however. If we wanted that, we would never release source again. Instead, as I said days ago, we're moving to mercurial and investing a lot in rearchitecting our entire code base to get fine-grained exports coming. This lets people more easily pick and choose. That's us *reducing* the amount of control we have over others' viewer structure by getting away from monolithic atomic exports, and making it *easier* to catch up. If we were the company you're portraying, we'd stop investing in better collaboration tools and go back to tarballs, as when the viewer was first open sourced. > perhaps even implemented as proprietary binary plugins > outside the project. The TPV > policy has already established that Linden Research will set > capabilities requirements, and the means to deny connection to viewers > they don't like. The intent of that policy should be pretty clear, by looking at what it's prohibited. Content theft, griefing and resource abuse have been long-term problems. Despite repeated assertions to the contrary, it's done nothing to tell people what they can't do with the viewer source. It informs what one can't do when connected to our service with any viewer, regardless of its origin. It also informs what viewers we're willing to list in our Viewer Directory. If there's anyone can make the case that either of these goals are unreasonable, that's a good discussion to have. > It will be instructive to see how mesh support is implemented, and > what role DRM plays in that implementation. The server side of that is > naturally proprietary, as is the rest of the server. One can't help > but wonder what will we see happen on the viewer side. If we can see > anything at all. Remember that you speculated on that. You can later evaluate similar worries based on real experience. > To draw a metaphor from the structural view implicit in your quote > above, your company can no doubt act to prevent this open-source tail > from wagging the Linden Research dog. That may involve "throttling" > to the point of amputation. That depends entirely on having a mutually beneficial relationship with the external developer community. I'd hope we stop publishing if we think the community would do us a net harm. I'd also hope you leave if you really believe we're solely out to exploit you for whatever patches you plan to offer someday. As I said, nobody's been forced to take a loyalty oath. Sacrifice shouldn't be expected of the Lab, or of any external developer. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
