How could SL go open source and be profitable?

Fascinating thread, I'd like to thank blaze to point it out for me and some others...

Well, before the war between open source and proprietary software breaks out again, and we all completely miss the point, perhaps I could just add my L$ 0.02...

Most companies that I know who have gone towards the route of "open source software" (and I'm personally still working for one...) have had a very distinct business plan: their core business was never on the application that was released as open source, but either on the services provided with that application, or from an entirely different source (ie. their core business was not software development). A very few just released the source code on an application that had paid itself over and over again, and the cost of the license simply scared customers off. It made more sense to give the application away for free and charge more for the services instead

Now, Linden Lab does certainly fit in that type of company (while Microsoft certainly does not). Their core business is hosting 3D content servers. They could either use third-party software for that, or develop their own. Given Philip's background, and the lack of a proper solution back in 1999 when he started to write what would become the "core" of Second Life, it's not surprising to see that they preferred to invest on their own software. So, unlike so many others, Linden Lab is currently the only company providing hosting services for 3D content. Others are merely entertainment/gaming companies, software developers, or 3D content creators (who happen to have developed their own platform for VR).

Under these assumptions, open sourcing the software makes sense, since it's not the software that provides a regular stream of income. However, there is a slight twist on this model. By open sourcing the software and giving it away for free, Linden Lab would actually give direct competitors - upcoming 3D content hosters - an enormous advantage: a working product, which has some 6 years of development, for free. You'd only need a competent system administrator, some cash, and a co-location facility, and you could run a competing grid - beating LL at its own game.

While this is unlikely to happen even if LL gives the open sourced software away for free, it is a possibility. So, this means that LL has to make sure they're able to get a return for their investment, by "controlling" ths software development and its usage.

I'm not siding with Tcoz completely. Perhaps unsurprisingly, since I've worked with software companies leading open source projects (well, neither as a developer or a project manager, lol, so I guess my information is probably inaccurate in many details...), what happens in this case is that a "core team" of company-paid employees mantain most of the code and directs the development. Volunteers contribute to the project with code which is quickly evaluated and integrated into the main branch of development. This model works pretty well with Apple and the Darwin project, or MySQL, or Sun, or so many others. I'd be so bold as to say that this is one of the best ways to deal with open source projects. The other "best way" is building the team from the bottom up, and have a consortium/foundation/organisation dealing with the central project management (eg. Debian Linux, Apache, Mozilla, and, well, W3 with HTML, I suppose). Still, exceptions exist - phpBB seems to be one of those projects that has grown huge without a central authority, and is certainly very successfull. The only criticisism I can make is that many of those projects who are not backed up by a company or an organisation tend to be highly risky - they may be a big success as easily as a big flop, and it's hard to tell what will happen soon.

So, project management is not really the issue with Second Life - LL would certainly provide that, and simply add a host of volunteers to help with the bug fixing, feature requests, and all sorts of stuff that gets added creatively and who nobody thought/planned before.

The issue is, making a profit from an open technology which could potentially be used by competitors to do a much better job with it, even if "competitors" simply mean "helpful individuals" in this context, and not really organisations (imagine thousands of volunteers "donating" their Internet-connected computers to host sims for free...).

A few examples have been suggested, like in-world advertising, and similar ideas that have sprung in the "old" New Economy. We all know how these worked out so I guess that Linden Lab has to do a bit more than that.

On my own blog (sorry, no shameless plugs this time, I've done enough on the forums already ) I suggested a few ideas. They're not really "mine" - they have been collected from input gathered either in-world, on the forums, and during RL conversations. One way is to think of Linden Lab as becoming the next "Network Solutions" of the metaverse. As most of you know, Network Solutions ran a "virtual monopoly" for almost a decade by managing the DNS root nameservers. For those that don't, you can easily understand that "someone" has to point your lovely www.mydomainname.com to a physical box. They charge a small fee for that.

In terms of Second Life, what this means is that Linden Lab could act as both a "certification authority" and as an enabler of peering agreements. The first idea was suggested on this thread (well, actually, I think that several people arrived at the same idea at the same time, hehe - similar minds think similarly!). If you have local (ie. sim-based) authentication, as opposed to "centralized" authentication, you need a way to make sure people cannot create accounts that have been used elsewhere. The beauty of this approach is that you need to ensure this only when creating your account. From there on, you can simply log in to the sim your avatar is tied to, and everything else will work fine. Even if you tweak with your client or server software to display a different name, this is just a local issue - people using the "official" client from LL will have the correct names displayed. So you'd look a bit silly hacking your name to be "Philip Linden" and bragging about it when everybody else in the metaverse would see you logged in as "Anonymous Coward"

Non-certified avatar names would simply be unusable outside of the sims they were first created. So you'd have an "isolated sim" in that case - very similar to what happens in intranets, where you can set up your computers' names as you wish, but if you haven't a "registered" name, you'd be unable to use it beyond the intranet.

The same would apply to servers connected to the metaverse: a digital certificate to be applied to all content there, to make sure it's unique, properly catalogued, and trackable to its origin (creator/owner/sim where it's stored). If this is done properly, you would even be able to make sure intelectual propriety is not violated - or, if it is, a way for you to easily track down the culprits. Of course, if someone running a non-LL sim has been a recurrent source of abuse, LL would cancel their certificates. That would mean that all those objects would simply vanish from the metaverse (and be only available at the local sim, for the very few avatars created there in the first place). Legally speaking, I'd guess that US law is able to deal with these cases pretty easily, since it's the same principle under which the digital certification authorities or the DNS system work.

So this would be one of the sources of income. How much should LL charge for them? Well, it sounds pretty easy to figure out: US $9,95 one time fee for an avatar certification, US $198/month for an ongoing certification of a metaverse-connected sim Sounds familiar, right? LL could give a discount on both fees, since they wouldn't be providing any technical support to either the avatars created on non-LL sims, neither to the sim itself.

But there is more to earn with "peering agreements". Imagine the best-case scenario: a parallel grid, operated by a LL competitor, is able to have the same amount of content and avatars created on "their" grid, as LL has on its own grid. This means that the traffic between both grids is almost the same - ie. that textures, anims, sounds, objects, avatars flow in both directions, in the same amount. Under these circumstances, it makes sense that no one charges the other for traffic. But now imagine the reverse situation. A single sim has just 20 avatars created there and a dozen objects. Almost all content will be downloaded from LL's "main grid", and the single sim will not contribute much to the overall metaverse. This is unfair for LL's grid - they're actually providing lots of hosted content for their "competitors", and getting almost nothing in return. The telecoms and major ISPs have dealt with this issue by devising "peering agreements". This mostly means that equal-sized peers don't pay anything for being interconnected - both share the same amount of content - but smaller-sized ISPs pay a large fee to get connected to the big ones. While this may seem unfair - it promotes a "cartel" of ISPs over the tiny independent operators, who struggle to pay their peering fees - it also contributes to a degree of self-regulation. Residents trust LL with their content. They would probably trust an independent organisation about the same size of LL. However, with open source server software, which you couldn't really know if it was "tampered with" in any way, you couldn't really trust much the tiny grids. They would need to grow, building on their credibility, until they became large grids - and then, the peering agreements would be much nicer for them

So, under this model, Linden Lab would actually profit more by "giving the code away" than under the current model of a "centralized, proprietary grid". And I'm not talking about profitting more "ethically", or by "reducing costs of development" by using external volunteer developers to fix bugs and add features, but really, make more money, since others would expand the grid not only without extra costs for LL, but by actually paying for the privilege of being interconnected! Thus, under this model, LL would not be "selling licenses" or "making people pay to use their wonderful technology". No: they would capitalize on an asset - a large grid at the "core" of the metaverse, which everybody wants to connect to, and willing to pay for it - and keep to their core business (regulating the way the metaverse is built), while at the same time putting a few safeguards in place by protecting content and avatars which are not under their direct control. Sure, I expect that many people will create tiny, independent grids and not pay LL a dime for that privilege. I also expect those tiny, unconnected grids to be insignificant - or eventually "testing grounds" for amazing new ideas, too radical to be developed on the main grid - but they won't "survive" until they are interconnected to the "main grid". This is a similar development to the move that BBSes in the pre-Internet world made - some tried to stay isolated, but most tried to "join forces" and slowly interconnect themselves, first using their own techniques and protocols, later by simply "merging" with the bigger Internet. I'd expect the same thing to happen with the metaverse. And LL would still be able to keep their "control" of things.

I don't know. All this made a lot of sense a few years ago, when the commercial Internet started to grow exponentially (and earlier than that, with the world-wide telecom infrastructure). Perhaps it makes sense for the metaverse as well. Or perhaps a better model is needed. Who can tell?

As far as FOSS goes...

about 80% of it is not very elegant and great software.

One major thing FOSS or OSS lacks is good, researched, and tested UI.

I tend to agree more with Antagonist --

If we consider that the way to get profits is through efficiency, then OSS and possibly even FOSS will become an invaluable asset and may eventually drive the software industry.

However, commercialism is pretty much here to stay. I don't think we're capable of a zero-cost society -- complex goods manufactured by humans will always cost something. Money is just the intangible we use to trade our efforts and skills for tangibles.

(poverty and other money issues are thanks to lacklustre governments).

Ultimately though, there is a tonne of FOSS available and I use almost none of it. Mostly because FOSS developers don't develop UI very well and a rediculous amount of the software produced is developed for developers....

so proprietary it is for now. I just think the proprietary guys should start rethinking pricing strategies and curb the greed. IP/copyright/patent laws definately need to be reformed. Big time.

Blaze, that was an excellent posting of material from Mitch's blog. Thanks.

That was a very good analysis, Gwyn, right through the article.

I would actually go further though, and suggest to you that if LL's vision is truly set on being the major corporate player in a future multi-billion dollar industry that capitalizes on an open metaverse akin to today's open Internet, then LL's current code base has zero dollar value as an actual product towards that goal.

It has value, yes, but that value is almost entirely in what it says about Linden Labs, namely that this is a company dedicated to 3D virtual worlds of a very open kind. Profits of a few million stemming from this codebase are utterly insignificant in the context of the riches on offer in that future towards which Philip has stated that LL is heading.

The "sound business plan" reasons for harnessing the power of the open-source community are strong enough even on their own, but given LL's expressed end goals, it seems to me that the benefits derived from being in the forefront of helping to develop that metaverse are even greater.

This doesn't necessarily have to entail open-sourcing existing product if this bears little relationship to the systems that will eventually be built. It does however necessarily entail contributing *something* for the desired perceptions to be maintained. I would suggest that contributing a few streaming protocols and interfaces as metaverse seedcorn, plus engaging in technical discussion about the way forward, might be an effective start.

As someone who actually went ahead and built an OpenSource version of SecondLife (http://metaverse.sf.net), my thoughts are:

1. This concept that making something OpenSource suddenly brings in a million developers is flawed. Most people just want a product that works, out of the box. Hey, installing a product is almost too much work for many
   
2. Mostly people want their cake and eat it: they want a perfectly finished product, that they can tinker with. They dont want to actually build that perfectly finished product
   

The best description I've seen of where and when FOSS works - and when it doesnt - is in this article:

http://www.moonviewscientific.com/essays/software_lifecycle.htm

Basically, this states that software, like cars or any other product, goes through a lifecycle:

1. Stage 1. Invention
   
2. Stage 2. Expansion and Innovation
   
3. Stage 3. Consolidation
   
4. Stage 4. Maturity
   

However, software is different from cars: once you've created a piece of software, the cost to duplicate that, to create copies, is negligible.

And so, the essay argues, this leads to a fifth stage in the lifecycle of software:

1. Stage 5. FOSS
   

(Actually, the author argues there are two additional stages: foss dominance and foss era, but I'd simplify that a little to just one)

This makes sense, and it certainly seems to corrolate with what we see today.

FOSS that works consists of software that has at least reached its maturity phase, for example:

1. text-based operating systems (Linux) (some might say operating systems in general)
   
2. word-processing, spreadsheets, presentation software (OpenOffice)
   
3. etc
   

Clearly, if this is the only criteria in the success or failure of FOSS, then OpenSource SecondLife is basically doomed.

However, I'd argue that there is one more criteria:

1. extent to which software and features are used by, and relevant to, developers
   

However, that may not be enough to save OpenSource SecondLife, because SecondLife is not just about scripting: it's graphical, it's artistic.

It's fairly easy to predict that an OpenSource version of SecondLife would have awesome scripting facilities, but one's avatar would look like poo. This is basically the case

Going back to "having one's cake and eating it", it's interesting to note that some of the most vociferous proponents of making SecondLife opensource baulk at the idea of actually contributing concrete code to SecondLife-like projects themselves. They'll stand on the sidelines and tell you what to write, but they wont actually take that little step of actually putting their words into code.

As for me, I'm just going to wait and see what happens for a while. Maybe SecondLife will do everything I need; maybe some miracle will happen and people will start contributing to OSMP development. If neither are the case, in a couple of years OSMP may be developed on a commercial basis.

And that, really, is probably the end of this discussion? If the OpenSource project that is available is considering becoming closed source, why would the closed source one become opensource?

It will certainly happen, but I do like the concept of the software lifecycle a lot - and that article above in particular. In other words, as long as metaverse-software is cutting edge - and it's certainly going to stay so for a wee while yet - closed source will most likely dominate.

Course I'd love to see myself proved wrong

Azelda

I really agree with this part. A really good example of this is Mozilla -- it took a couple years for a really usable client to come out. YEARS! As JWZ says:
Basically, unless the Lindens can release the source to the full, working client, and have it actually usable as-is, I question whether or not it's going to be worth it at first.

(Please note that I wholeheartedly support opening what source LL holds the rights to, insofar as asset security can actually be maintained.)

That was a very interesting post, Azelda. I'm currently reading that Craig A. James article that you linked, spotted quite a few good points there already.

What's the current state of OSMP? Could you give us an update on it, please?

That article by C.A.James' linked above by Az is a very interesting read -- I recommend it to anyone who is already immersed in FOSS, less so for new recruits to the area.

It fails slightly by the author trying to push all FOSS development into the same 4-6 stages ... needless to say, the world isn't like that. What he writes describes the process undergone by a few examples quite well, but the vast majority I can think of fit very poorly into his model, at best. What he writes isn't wrong, it just doesn't apply in the general case because there is no general case.

Also, because he is so focussed on his 6-stage model, the article doesn't actually mention at all why FOSS necessarily becomes the future of all projects that capture community interest, and why comparative failure is pretty much inevitable for all commercial competitors.

The reason is simply that in an active project, FOSS provides compounded iterative development without end, and the vast majority of commercial development simply cannot compete with the mathematics of that over the long term. The article might be incomprehensible to non-FOSS people by not mentioning the main reason why FOSS superiority is inevitable in the long run, unless they just guess.

There is another problem with the article unfortunately, and it may be even more fundamental than the last one. The author sees every FOSS project as separate and distinct, whereas the exact opposite is true. The focus of each FOSS developer is certainly on just one or a very few projects, but the FOSS community as a whole applies itself to thousands of projects in parallel in a beautifully unmanageable mess. They all build upon each other, creating a very synergistic groundswell of activity covering numerous areas.

In other words, FOSS results in the creation of a pyramid of faciliities, with each project building on top of what others have done, in a massively self-reinforcing life cycle that is completely absent in James' analysis. It's yet another reason why proprietary development is on a hiding to nowhere, because commercial projects simply do not combine to create an ever more powerful software base for those that follow.

Despite the above, James has an interesting point of view, and it definitely applies well in a few cases.

Let's assume for the purposes of my following question that LL's opened sources might provide a valuable kickstart in the direction of an open metaverse. (It's not necessarily a given.)

Given that premise, are you saying that protecting the existing assets within the small proprietary world of SL should be a reason for denying Lindens the possibility of a lead role in a future multi-billion dollar open metaverse industry?

That would be an odd strategic choice to make, it seems to me.

/me *applauds*

Yes, thanks a lot for both your post and the link to the awesome article by Craig James. Somehow, I almost pity Bill Gates Then again, I can't forget that he has a 10% stake on a company using a FOSS operating system - namely, Apple. I wonder if 80-year-old Bill Gates will be remembered by his vision in preparing the survival of Microsoft through Apple ("after all that fuss, he always knew what was going to happen in the Windows world..." or by his dedication of stamping out the FOSS effort for over a decade. Hmmm. According to Craig James, we're certainly living in interesting times

As to the lessons that Linden Lab has learned from articles such as this, I guess that the message is pretty clear. An Open Source Second Life? Yes, but Not Yet. It's too soon.

I agree, Azelda. There is not much more to be said about this You can argue emotionally, but if you want to be objective, I'd say that Craig James' arguments are pretty hard to counter-attack.

Excellent stuff

Oh, BTW, Azelda, I just saw that the "Official Feature Voting" site is now up I guess this isn't a surprise to you, but I'm very glad LL finally put it up. I hope that they'll credit you profusely

There's our chance to vote for the native Linux client folks. Don't give LL the opportunity to say that there was no interest. The SL Feature Voting System is here.

I also voted for "Prop: 66 - Open up SL in a way that outside (of LL) developers can help ". I have no idea what it might mean in practice, but any slight moves towards openness can't be bad.

Incidentally, the whole voting forum thing is needed only because SL hasn't gone open source, and therefore feature takeup is subject to LL's manpower restrictions so prioritization is necessary. Even then though, it's not a panacea, since suggestions still require lead designer acceptance and signoff, and there isn't even a medium available to support that, let alone any indication of a desire within LL for it. The Discussion links within the voting system could be used for that in principle, but seem not to be.

And the concept of majority voting on technical issues is pretty bizarre ...

Asking for developers to help SL along is an interesting proposition, one I believe is already available in a very real way.

Build content. That is most definitely a signficant way developers can help SL move the software forward. I think a lot of people undervalue how much LL needs developers to get in there and really do something special, stable, and with some longevity. To date there are very few (I'm not talking about casinos).

I understand the different kinds of development. But if you are a developer, you absolutely can help LL out by trying to build something like a framework for LSL (something in fact I've been toying with for about a month), a large gaming system, something of that nature. It gives you a great understanding of the limits of the software, and LL will very much be interested in your thoughts and what they can alter. Although it hasn't happened recently, it did not used to be unusual for a Linden to show up when you were working on a big project and get interested in the details and how SL could be altered to make the software more enabling. I'm willing to bet a paycheck that Mr. Tringo provided LL with some very real developer chat and some specific recommendations, which I'm sure they will take dead seriously.

The opportunity to engage the SL developers very much exists, just not in a "here's the IP of our CVS repository" way.

Building content and building infrastructure are entirely different things though, Tcoz.

As an example, everyone already understands perfectly that LSL lacks O(1) indexed arrays and therefore erects an absolute efficiency barrier that hampers the development of a very significant category of solutions. There is no need for further user experience to know that, and user-level effort cannot overcome it.

In contrast, if the community had had developer access to the infrastructure then this issue would have been overcome within weeks of launch.

Correct. It's available only in a completely ineffective way ... otherwise LSL arrays wouldn't still be on the feature voting list after all this time.

Morgaine, I very, very much understand the difference between the kinds of dev. I offered a positive option, and have done so more than once, and you simply appear to be getting into a pattern of trying to naysay everything I say. It's getting tiresome.

Regarding arrays, here is where you could contribute.

Build something significant. Get the attention of the developers. With this dialogue, begin to make a case for alterations or additions to the family of array mechanisms available (or the orphan child rather) and how these things specifically would assist your efforts.

So now you are feeding real info into the devs that are building the infrastructure. I'm sorry if you don't agree, and you obviously don't, but I perceive this as being not much less significant than actually working on the code for the infrastructure. In large software projects that my team undertakes (we are currently in full on QA for our most recent project, squash them bugs) we take everything the hardcore testers and early adopter users say seriously, and the more technical the recommendation, the better. We in fact made an alteration to a layer of our framework we loosely term the "Model Manager" based on the recommendation of an early adopter client. That was a core infrastructure change, not a trivial UI one.

So, although I have tried to avoid it up to now, but you have not, I will take up the gauntlet and state that I disagree strongly with your absolute position on open source, and that you appear to have no experience in managing large software projects that people are paying money for and need done sooner than later.

I would now ask that you please, please do NOT address me by name in the forums. I will reciprocate. Thank you.

O(1) indexed arrays don't require justification, they don't require majority voting. And their utility certainly doesn't require proof in an example application. That utility is apparent to anyone who attended the first day of Comp Sci 101.

Please, let's not get silly.

Lol.

Whatever you say Morg. However, having built a large gaming system in world, and having been asked by the Lindens regarding the technical challenges, I could not say arrays were a substantial barrier to my success. Lists, as they exist (and as long as they are stable) fulfilled my need perfectly. I just needed to consider alternatives. LSL is not intended to be a full on programming environment.

Maybe you just need to get out of that CompSci1 think box. Perhaps consider compsci 2.

I apologize for this folks. I will not respond again as I am now ignoring the parties that seem intent on attacking me.

And I'm very glad that lists worked for you in your application.

However, normal lists do not have an O(1) access mechanism, so all your post is really saying is that your application did not require O(1) scalability. That's fine, for you, but it says nothing about anyone else's requirements.

The fact that others have called for arrays (since the earliest of days) or any other kind of access mechanism with O(1) scalability says it all. I find it no surprise whatsoever, as it's elementary functionality in any computing system.

Addendum. We may have got slightly sidetracked here. I mentioned O(1) arrays as a very concrete example of how SL (or in this case, just LSL) not being open-sourced has acted against community improvements that would have been hugely beneficial to LL. Hopefully the efficiency benefits of O(1) operations on servers need no further explanation.

Catherine Omega posted a quote from jwz which I think hit the nail on the head: (extract)

That's very insightful I think, it certainly works for me.

I think the moral here is crystal clear.

Make your open-source projects install trivially, make them resolve and fix their own dependencies, and provide fallbacks for when dependency resolution breaks on the target. Always use one-step builds, and factor everything into tiny parts that contributors can understand, not just the lead architect. Incorporate a small, self-contained revision control system to manage people's changes automatically within the build, and detect changes and check them in by default on make, without requiring the (possibly inexperienced) person to do it manually. (The deltas might one day even make it upstream, wow! )

Of course, none of us create projects with all these desireable properties, or at least I don't --- but I should, and indeed everyone in FOSS should.

I'm going to comment on Blaze's original thread-starting post and Lordfly's ammendment to it, because really they contained everything that is needed for success in this area, as I see it.

Yes, that's a given. Protection mechanisms merely raise the bar that needs to be overcome, they never do more than that. You simply cannot protect in any meaningful way against someone who has full control over their own machinery. The best approach is simply to make it not worth the effort.

If the price of CDs dropped to pocket-change numbers, fans would be buying hundreds of CDs per month, every album that sparks their interest, irrespective of online music (or maybe even to feed it) --- a point totally lost on the RIAA.

Well certainly not off the client --- that's merely a necessary tool for accessing the servers, and a major load on their resources and a liability to their success. Development doesn't come cheap, and LL has way too much work on its plate already just working on server-end upgrades. Only an infinitessimal fraction of the many great ideas that people propose ever get worked on, and I don't think that it's because LL don't like them. They just don't have the manpower.

I contest this.

First of all, you haven't given any reason why they should feel a squeeze. They will be first in the field, they'll have the systems already running, they'll have the management tools to remain in the lead while competitors first have to develop them. And they'll have the good will of the community because their openness has been remarkable and there is no reason to believe that this will stop.

On top of that, they have a ready and successful world in which people have already created content, so competitors lag far far behind. I don't see any squeeze vector.

Of course, there is the possibility of being squeezed out on pricing, but how realistic is this? Well let's look at their likely costs.

LL already runs pretty large server farms so they must be getting quite reasonable discounts, and these will just get bigger. And they don't pay the Microsoft Tax, so there is no unnecessary licensing drain on their bank balance in that area. And they already employ a lot of open source products, so the FOSS community is already working (in a small way) on their behalf, unpaid. As I see it, there is little room for being squeezed out on costs by anyone, and their profits through sim pricing can be lowered just as easily as those of the competition.

Lordfly Digeridoo's post suggested a business model in which the SL client is immediately open-sourced, whereas the server end is not open-sourced but instead is licensed by LL to larger customers as an alternative to buying their own sims. I can't comment on the monetary aspects of licensing server code vs renting islands, but splitting the problem into those two parts is an excellent idea.

Not only would LL benefit enormously from shedding the burden of client development (although they would of course still contribute their changes to it), but any improvements that those 3rd parties who license server code might make to the client would automatically benefit LL as well. (This assumes that the GPL or similar strong license is used of course, since changers who distribute modified clients must be forced to release their modified code, otherwise the original authors do not reap the benefit of community.)

This looks to me like a terrific way of moving rapidly ahead with the help of community manpower on one fairly significant but burdensome part of the software base. And since FOSS is already contributing to some extent on parts of the server end, it seems a pretty natural progression too.

Not really related to open-source SL, but at least relevant to the main open-source platform ...

I've posted a short article containing the lines from Cory Linden's Town Hall that referred to work on the native Linux client for SL.

I think if the server went open source, they'd get squeezed, even if they were at the helm of development.

Someone would fork it and do a better job of hosting than LL does. Hosting is a race to the bottom except that the people at the bottom are very very street smart with kick ass technical skills.

However, if they kept the server closed source than their advantage, being able to set the license price, would be obvious.

Though, if the protocols did go open one starts to wonder whether an open source version of the server would be created by outside efforts?

The more analysis I do the more I believe that a lot of the talking about open source is really a way to scare off potential competitors from doing it and less that I believe that they're serious about it.

I could see licensing the server/clients at a cheap price. I am not so sure I can see opening the code.

I tend to agree with what Adam Zaius and Nexus Nash are saying -- not only is it OK to be making money from this, it may be a necessity when you think of the labour and machinery and housing needed to keep the open source moving.

While this appears to be merely a technical discussion on the surface, there are a lot of ideological presuppositions about forms of society lurking underneath it and these need to be addressed.

I don't see why SL wouldn't still have an existence the day after it opened up the code. Either it sells pre-fabs of experiences like "let's play house" or "let's play shooter game." Or its job then could be hosting, or most likely, orientation. It could by that time have developed a reputation that is service- and education-oriented (not just oriented to the development of the code and technology itself). With their expertise, they be helping people to adapt to the 3-D/metaverse idea. It's not an instant, intuitive thing, and people will need to compress and decompress into it just as they once did in deep-sea exploration or outer-space exploration.

I'm also going to continue to ask Morgaine to define what terms of law, or authority, or rule of law would govern the open-source grid. No law can become merely the law of whatever strong-minded grouplet starts disseminating memes and ideologies and norms of behaviour in this 3-D world.

There's also the question of "land" or "space" for living and moving and having your being in this world. Every time Morgaine talks about it, it's always brushed over -- land will just be spun out like stamping on tool-and-die -- there will be parcel controls to mist up everything around...or you level up endlessly in the sky to create the illusion of endless space..or??? But doesn't it all come to earth at some point? Isn't there a bandwidth issue?

If open-source predetermines that the inhabitants are all going to behave like already- socially-engineered lab rats that don't "need" land or don't "need" ownership, and all notions of rights and ownership have just been stripped away from them as "vestiges of the past," then I'd like to know Morgaine's plan for those that don't go along with this program.

While not having a handle on the technical issues here, I see the Linden claim that they hope to go open-source some day as merely a spin.

They sound to me like the Russian government does about signing the International Criminal Court statute. They sign, but don't ratify, due to Chechnya -- and they get credit for saying they did ratify, and will sign it someday but...there's this problem or that problem...but sure, they will sign it and follow the rule of law someday, sure...

Whereas the U.S. is more straightforward and not only takes its signature off the document, it says it will never ratify it because it sure as hell wants to make sure it never applies to American soldiers. So Russia can look good looking sorts kinda like it might sign it (though it never will) and the US can look bad by forthrightly NOT signing it...except you might get the US to sign it if you have a completely different government...and that's what could happen to LL if it changes management, too. Not unthinkable. No company is immune to "founding fathers'" syndrome.

Blaze, I tend to agree that it's far easier to see only a transitional approach to open source working out for LL at this stage, ie. with only the client being open-sourced. That would bring them the benefits of external unpaid manpower and rapid evolution, without giving market rivals instant access to competing platforms.

In answer to the subsequent "contributer" to this discussion, suggesting that open source could lead to world inhabitants becoming "socially-engineered lab rats" is pushing it a bit far even for your normal brand of illogic. Be that as it may, keep socio-politic theorizing in the right thread bub.

No, Morgaine. I and other citizens concerned about freedom are going to be *right there* paying attention to the open-source discussion very closely precisely because we're not interested in having people create the scaffolding of a world that is in fact illiberal and unfree, under the guise of doing something that is technically sophisticated or complex. We're not the dummies and illogical idiots you imagine. It doesn't take too much common sense to see what's up.

You've made your views clear in other forums and they can be debated there, sure, but Adam Zaius and Nexus Nash, as well as others, have countered your views here, simply on pragmatic business grounds, and I'm right behind them pointing out the ramifications of taking the non-business and utopianist approach.

Unpaid but enthusiastic labour all over the world? Endless property that is not owned by anyone really and therefore *not really* somebody's responsibility? Endless replication of a free or nearly free thing everywhere with no concept of its costs until it is too late? Sounds like another thing I know, but sure, I'll go somewhere else with continuing THAT discussion.

But what I'm doing is answering blaze's question: open-source *better be* profitable and those who want to spread SL in open source *better think* about how to make it so, because then it will have responsible adults backing it.