Not too long ago, a couple of folks have released forks of Firestorm, taking the source we've put a year of hard work into, making their own changes in it, and releasing it under a new name.
There's nothing wrong with that. It's an essential part of the open source software model.
What is wrong is that, in both cases, they did the open source equivalent of filing off the serial number: they removed any credit to Firestorm and its contributors. In essence, they claimed credit for the work themselves.
That's beyond the pale.
There are three main reasons people work on open source software: scratching their own itches, helping others, and gaining a good reputation in the community. The first two are obvious. Every Firestorm developer has added features or fixed code to do something they personally want to see done; the best examples are Zi Ree's Phoenix emulation and animation overrider, and Tozh Taurog's LSL bridge. The second underlies what all of us get out of it, to one degree or another. It's not entirely altruistic. We get warm fuzzes from people thanking us for the work.
The third one is what the two forks have destroyed. As much an economy as open source has is based on credit for work: not monetary credit, but reputation credit. I've cited open source guru Eric Raymond's essay Homesteading the Noosphere here before. In it, Eric describes what drives open source developers as a gift economy: people give away their work in return for credit, thereby enhancing their reputation in the community.
That means that removing credit for work is as close to theft as you can come in the open source world.
There have been complaints in the past that we have not properly credited others for their own work. This has been unintentional, and rectified as soon as the issue was raised. We proudly and happily acknowledge the work of others that makes its way into Phoenix and Firestorm to the best of our ability.
I don't know if the offenders have put the credits back. I suspect one has not; she has shown an ongoing pattern of taking others' work and removing credits before distributing it. The other is reported to have taken down his entire codebase, or at least have made it inaccessible.
One of the two claims that some developers asked him to remove their credits in his codebase. If someone asks that their credits be removed, that is their right, and he would be right to comply. I find the claim difficult to believe, however.
I would personally not consider using either viewer, myself. If they're willing to steal credit for others' work and break the norms of accepted behavior in that way, what else are they breaking?
I considered naming the two viewers and their developers. I decided not to. They have a tiny number of users, and I decided that naming them here might induce others to try them. If you encounter a viewer that looks a lot like Firestorm, though, I would strongly recommend checking the credits section first, and if the Firestorm team isn't credited, run the other way fast.
03 June 2012
30 May 2012
Death Sold Light Beer
My roommate, the incredibly silly ox, was one of an apparent multitude of folks who heard the chorus of Faderhead's TZDV not as "Tanz zwo drei vier", as intended, but as something else. In his case, it was "Death sold light beer".
This caused a stir around Gothika. One denizen in particular seemed to complain that she couldn't get that out of her head. Naturally, I had to turn that line into a full set of lyrics. Enjoy.
DSLB
Lyrics by Tonya Souther
With apologies to Faderhead
This is a song about the football clubs
This is a song about the drunk
This is a song for everyone who chugs
The barfers ride home in the trunk
This is a song for all the cheering fans
This is a song for all the geeks
This is a song about the scoring drives
This is the time to drink the yeast
Chorus:
And I say
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
And I say
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
This is a song for all the college kids
This is a song to make you fart
This is a song about fermented rice
This song's officially fine art
This is a song for all the booing fans
This is a song for all the geeks
This is a song about the sticky floors
This is the time to drink the yeast
Chorus
Miller beer
Coors beer
Heineken beer
Foster's beer
Miller beer
Coors beer
Heineken beer
Foster's beer
Death sold light beer
Chorus
And I say
Death sold light beer (light beer light beer)
And I say (beer light beer light beer light beer)
This caused a stir around Gothika. One denizen in particular seemed to complain that she couldn't get that out of her head. Naturally, I had to turn that line into a full set of lyrics. Enjoy.
DSLB
Lyrics by Tonya Souther
With apologies to Faderhead
This is a song about the football clubs
This is a song about the drunk
This is a song for everyone who chugs
The barfers ride home in the trunk
This is a song for all the cheering fans
This is a song for all the geeks
This is a song about the scoring drives
This is the time to drink the yeast
Chorus:
And I say
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
And I say
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
This is a song for all the college kids
This is a song to make you fart
This is a song about fermented rice
This song's officially fine art
This is a song for all the booing fans
This is a song for all the geeks
This is a song about the sticky floors
This is the time to drink the yeast
Chorus
Miller beer
Coors beer
Heineken beer
Foster's beer
Miller beer
Coors beer
Heineken beer
Foster's beer
Death sold light beer
Chorus
And I say
Death sold light beer (light beer light beer)
And I say (beer light beer light beer light beer)
09 April 2012
Building with mesh
I've been skeptical that I'd be able to deal with building with mesh ever since it was announced. I didn't see the point, and didn't think the tools were something I could learn to deal with. Over the past couple of weeks, I've changed my view.
I had thought that the only tool that I could use without spending piles of money I don't have would be Blender. I hate Blender. Blender is as user-friendly as Viewer 2 is popular among long-time SL users. Every time I run it, I want to throw my screen out the window without bothering to open it first. The official tools, like Maya or 3DStudioMax, are far out of my price range.
Then I got interested in sponsoring World Goth Fair 2012, a monthlong event run by my good RL friend Axi Kurmin to benefit the Sophie Lancaster Foundation. That's the kind of charity I can get behind, and I was happy to plunk down the sponsor fee and pledge a substantial portion of sales to the foundation's benefit. There's just one problem: None of my furniture is gothy.
I'm not a goth. I know bupkis about it, myself. My furniture design principles are simple, clean, and functional; I build with 2-inch aluminum plate for a reason. I've gotten pretty good at slinging pims, to the point I prototype that way. I've got a well-developed set of design rules I stick with when building furniture. They won't work for this fair.
I asked Axi at one of her world-famous Wednesday evening 80s sets at Gothika what I needed to do to make gothy furniture. My roommate, an incredibly silly ox by the name of Orvan Taurus (yes, he really is silly. Ask anyone but him.) chimed in with "anodize the aluminum". Axi said "you're not far wrong." Oh, really? Maybe I can do this. Axi showed me some furniture samples and explained what they were derived from. That didn't look too bad, so I whipped up a Gothic equilateral arch out of prims, ran them through a prim oven, and ...it almost came out usable.
Almost. The texturing had obvious seams. The point at the top of the arch where the arc prims met was just terrible-looking. When I applied my standard metal texture, it just plain sucked.
All right, time to bite the bullet and try mesh. Axi had suggested Google SketchUp as a mesh building tool. It was maddening at first, but the learning curve looked like it was actually surmountable. I made up an arch or two and they actually looked good when imported into Second Life.
Still, the project languished, until I realized I had another learning opportunity. Linden Lab was sponsoring a design competition to replace the theater used for Third Party Viewer Developers' meetings, and one of the requirements was that it had to be mesh.
I spent an evening, and then a morning, struggling up SketchUp's learning curve, but finally figured out how to do it. I came up with a simple, functional, usable mesh theater, with seating for 36 and a nice screen to show web pages on via Media on a Prim.
When it was done, I let my friend Helena Lycia at it. She's an experienced, accomplished builder. I thought I'd done well. She showed me I hadn't, and how to fix it so I did. I started out with screwed up physics and a prim equivalent of 209. When she was done, the physics were fixed and the land impact was down to 108. I took her lessons and redid things myself, and while I couldn't make 108, I did get it down to 114.
There's one step I don't like very much, but see the necessity for. SketchUp groups things in such a way that one of the chairs, for example, takes up several actual mesh objects. Helena showed me how to post-process it so that it takes up just one object - but the post-processing has to be done in Blender. Gah. At least it's mechanistic, so I don't have to actually deal with the damned Blender UI for very much.
(Aside: Firestorm doesn't do as well as LL's viewer at uploading mesh and getting the physics right. I'm hoping the Havok sublicense will fix that. There's another problem, too, and it boggles me pretty thoroughly: Analyzing the same mesh object for upload cost and PE 10 times will produce 10 values with more than a 50% difference from one end of the range to the other. How the hell can they make the process THAT nondeterministic?!)
I probably won't win the contest. Another entry is much more impressive technically, and since the contest criteria include "a showpiece of Second Life design", simple and functional won't get it. That's all right. I needed the learning experience.
(EDIT: No, I didn't win. I did pick up the L$1000 runner-up prize, and Oz nabbed a copy of it to put in Hippotropolis, on the other side from the official theater. I'm happy with that outcome.)
Now to go back and build the furniture. I've got a couple of weeks yet, and I'm sure I can build several pieces now that I know how to go about it.
I had thought that the only tool that I could use without spending piles of money I don't have would be Blender. I hate Blender. Blender is as user-friendly as Viewer 2 is popular among long-time SL users. Every time I run it, I want to throw my screen out the window without bothering to open it first. The official tools, like Maya or 3DStudioMax, are far out of my price range.
Then I got interested in sponsoring World Goth Fair 2012, a monthlong event run by my good RL friend Axi Kurmin to benefit the Sophie Lancaster Foundation. That's the kind of charity I can get behind, and I was happy to plunk down the sponsor fee and pledge a substantial portion of sales to the foundation's benefit. There's just one problem: None of my furniture is gothy.
I'm not a goth. I know bupkis about it, myself. My furniture design principles are simple, clean, and functional; I build with 2-inch aluminum plate for a reason. I've gotten pretty good at slinging pims, to the point I prototype that way. I've got a well-developed set of design rules I stick with when building furniture. They won't work for this fair.
I asked Axi at one of her world-famous Wednesday evening 80s sets at Gothika what I needed to do to make gothy furniture. My roommate, an incredibly silly ox by the name of Orvan Taurus (yes, he really is silly. Ask anyone but him.) chimed in with "anodize the aluminum". Axi said "you're not far wrong." Oh, really? Maybe I can do this. Axi showed me some furniture samples and explained what they were derived from. That didn't look too bad, so I whipped up a Gothic equilateral arch out of prims, ran them through a prim oven, and ...it almost came out usable.
Almost. The texturing had obvious seams. The point at the top of the arch where the arc prims met was just terrible-looking. When I applied my standard metal texture, it just plain sucked.
All right, time to bite the bullet and try mesh. Axi had suggested Google SketchUp as a mesh building tool. It was maddening at first, but the learning curve looked like it was actually surmountable. I made up an arch or two and they actually looked good when imported into Second Life.
Still, the project languished, until I realized I had another learning opportunity. Linden Lab was sponsoring a design competition to replace the theater used for Third Party Viewer Developers' meetings, and one of the requirements was that it had to be mesh.
I spent an evening, and then a morning, struggling up SketchUp's learning curve, but finally figured out how to do it. I came up with a simple, functional, usable mesh theater, with seating for 36 and a nice screen to show web pages on via Media on a Prim.
When it was done, I let my friend Helena Lycia at it. She's an experienced, accomplished builder. I thought I'd done well. She showed me I hadn't, and how to fix it so I did. I started out with screwed up physics and a prim equivalent of 209. When she was done, the physics were fixed and the land impact was down to 108. I took her lessons and redid things myself, and while I couldn't make 108, I did get it down to 114.
There's one step I don't like very much, but see the necessity for. SketchUp groups things in such a way that one of the chairs, for example, takes up several actual mesh objects. Helena showed me how to post-process it so that it takes up just one object - but the post-processing has to be done in Blender. Gah. At least it's mechanistic, so I don't have to actually deal with the damned Blender UI for very much.
(Aside: Firestorm doesn't do as well as LL's viewer at uploading mesh and getting the physics right. I'm hoping the Havok sublicense will fix that. There's another problem, too, and it boggles me pretty thoroughly: Analyzing the same mesh object for upload cost and PE 10 times will produce 10 values with more than a 50% difference from one end of the range to the other. How the hell can they make the process THAT nondeterministic?!)
I probably won't win the contest. Another entry is much more impressive technically, and since the contest criteria include "a showpiece of Second Life design", simple and functional won't get it. That's all right. I needed the learning experience.
(EDIT: No, I didn't win. I did pick up the L$1000 runner-up prize, and Oz nabbed a copy of it to put in Hippotropolis, on the other side from the official theater. I'm happy with that outcome.)
Now to go back and build the furniture. I've got a couple of weeks yet, and I'm sure I can build several pieces now that I know how to go about it.
The Lab gets one right
At last Friday's Third Party Viewer developer's meeting, Oz Linden announced an upcoming program to let TPVs sublicense the Havok libraries that LL is using in the viewer. This is a good thing, and LL deserves to be applauded for getting this one right.
LL uses the Havok libraries in the viewer for two things: to do some analysis on mesh objects at upload time to assess their costs on the SL infrastructure in order to assign a prim equivalent (PE) value, and to edit the mesh used for the pathfinding feature currently in development. TPV developers have worked around the first library, with results that are usable if not as good as LL's; the second is very new - large parts are still in development - so that we haven't had a chance to do so yet.
Havok is the physics package used in SL. It's hideously expensive. LL uses it because they have to. TPV developers can't afford it themselves.
I'm very pleased that LL found a way to let TPVs sublicense it. I'm sure it cost them some extra money. It also requires that they place no small amount of trust in TPVs not to let it leak to unauthorized people. For those who think LL would rather see TPVs wiped out, this is a clear demonstration that it's nowhere near that simple.
The sublicense carries with it some pretty substantial restrictions:
LL uses the Havok libraries in the viewer for two things: to do some analysis on mesh objects at upload time to assess their costs on the SL infrastructure in order to assign a prim equivalent (PE) value, and to edit the mesh used for the pathfinding feature currently in development. TPV developers have worked around the first library, with results that are usable if not as good as LL's; the second is very new - large parts are still in development - so that we haven't had a chance to do so yet.
Havok is the physics package used in SL. It's hideously expensive. LL uses it because they have to. TPV developers can't afford it themselves.
I'm very pleased that LL found a way to let TPVs sublicense it. I'm sure it cost them some extra money. It also requires that they place no small amount of trust in TPVs not to let it leak to unauthorized people. For those who think LL would rather see TPVs wiped out, this is a clear demonstration that it's nowhere near that simple.
The sublicense carries with it some pretty substantial restrictions:
- The viewer it's part of must be LGPL, or licensed under some other license that allows linking with closed-source libraries. As Oz put it, "we're not going to help you violate the terms of your license." As a practical matter, this means that GPLd viewers need not apply. That, in turn, means that no V1-derived viewer is eligible, since those are all GPLd. The Exodus viewer is not eligible either until they finally relicense themselves under LGPL - which will let them join the TPV community instead of merely taking from it.
- Be listed in the TPV Directory. This one matters because it gives LL some recourse if the library leaks. I would presume that each TPV's copy of the library will be stamped in some way that lets the source of a leak be traced.
- Be substantially based on current LL code for those things that use Havok. I'm not sure just how strictly this one will be interpreted, but it can be read to mean that the TPV has to be fairly close to the current released LL viewer.
- The linked page says "be focused on Second Life". The actual license is stricter than that: paragraph 1.1(b) of the agreement says "Sublicensee must require the Third Party Viewer to connect only to servers owned or operated by the Company". We don't know yet whether we'll have to rip non-SL grid capability out of Firestorm yet to use this license, or if simply disabling the code if the viewer is not connected to SL is sufficient. We're really hoping the latter, as we're not going to drop OSGrid support for this or any other reason. If we can't, we'll have to produce two versions, one with and one without.
I don't see the restrictions - especially number 4 - as being a major deal. Looking at it from LL's perspective, it would make no sense at all for them to spend money on the library sublicense agreement with Havok only to have TPVs use it to help out their competition!
This is a very positive step for LL to take for TPVs. I'm pleased, and hope that more goes this way. It shows a true partnership between the Lab and TPV developers, something that's been lacking ever since the last round of TPV Policy changes.
24 February 2012
LL's Third Party Viewer Policy changes: Screw you, developers!
LL today announced, in a very contentious meeting, four new sections for the Third Party Viewer Policy. From the posting on the SL blog/forum:
The first outlaws true online status as shown by Phoenix. In the process, LL will break function used for other reasons then being eeeeevil: the llRequestAgentData() LSL function I used in this post to show a user's true online status will now only work for the owner of the scripted item and the creator of the script - or so we were told. Since the creator of a script is lost when the script is placed in a prim, that doesn't make much sense. If the Lab provides a way for legitimate users of the data to deal with their needs some other way, that's great; on balance, it's a win, though it's going to break thousands of items inworld.
The other three are simply LL telling TPVDs how the cow eats the cabbage.
The second bans the viewer tag system used by every TPV except for CoolVL. The stated reason is to protect the user's privacy, with an aside about people being bullied into switching. The politest term I can use to comment on that reasoning is that it's bullshit. What it's really about is LL not wanting people to know that their viewer is used by a minority of the user base, and that there are other viewers out there that are much more popular because they fail to suck.
The third is similar. There was some question as to whether turning on RLV was sufficient opt in to enable the @version reply message, which includes the name and version of the viewer; Oz said it would be. It also permits the use of the feature that shows whether a user is using Phoenix or Firestorm in the support groups, if they opt in (currently, that setting is opt-out). So yeah, they threw us a bone. Even so, the effect of these two is to greatly diminish the effects of the overwhelming majority of users running something other than the official viewer - which is exactly what LL wants. Their thinking, which they won't admit to but is blindingly obvious to anyone who looks, is that they hope to keep people from migrating away from their viewer.
The last is the worst. It prohibits TPVs from developing features for Second Life that won't instantly appear the same on the official viewer. Many of the features that users have requested most - multi-attach, avatar physics, parcel Windlight to name three - started out as features that TPVs introduced. They were all proposed to LL before they were introduced, and got shot down in flames; LL's use of the first two features came two years after they were introduced. The third doesn't exist yet in the official viewer, even though LL asked us not to introduce it before they did - and that was fifteen months ago.
Now they want us to submit proposals to them through the official process, then work with them to develop them in the official viewer, and only when the official viewer can show them can we roll them out in the TPV. Let's see...they can squash the feature entirely, after taking however long they damned well please to even look at the proposal; if they do accept it, you can't develop it in your own viewer, but only in the craptacular official viewer; and they can roll the feature out in the official viewer immediately when it's done, but we have to wait for that before rolling out our own.
This puts LL completely in control of our development cycle if we do have a new feature that's somehow survived the gauntlet. Worse, it's not symmetrical: the Lab can develop new things in secret, and spring them on an unsuspecting grid, leaving TPVs to catch up as best we can - and Oz said today they would continue doing that.
This limits TPVs to working in the UI, leaving actual improvements to the SL platform entirely at the mercy of LL. Tell me why we're supposed to be other than thoroughly pissed off at this?
The last paragraph is ripe with possibility for unintended consequences. Oz said that RLV would not be banned under that policy, and that parcel Windlight was getting a free pass - but only until LL got off its ass and released their version. I'm not holding my breath for that one. Look how long we've been waiting already. I'll also not believe that they'll do other than develop it in secret, without our participation, and then demand we remove it immediately, without giving us time to adapt the feature for our viewers, until it actually happens - and then only when it's a fait accompli. Oz also swears up and down that the process will be different. I'll believe that only when I see it, preferably several times.
No, we're not happy with the changes in the TPVP. We're stuck with them anyway. Fuck you too, LL.
Here are the new sections of the policy:Taken together, these changes are a big fat "screw you!" to TPV developers, with one exception.
2.a.iii : You must not provide any feature that circumvents any privacy protection option made available through a Linden Lab viewer or any Second Life service.
2.i : You must not display any information regarding the computer system, software, or network connection of any other Second Life user.
2.j : You must not include any information regarding the computer system, software, or network connection of the user in any messages sent to other viewers, except when explicitly elected by the user of your viewer.
2.k : You must not provide any feature that alters the shared experience of the virtual world in any way not provided by or accessible to users of the latest released Linden Lab viewer.
The first outlaws true online status as shown by Phoenix. In the process, LL will break function used for other reasons then being eeeeevil: the llRequestAgentData() LSL function I used in this post to show a user's true online status will now only work for the owner of the scripted item and the creator of the script - or so we were told. Since the creator of a script is lost when the script is placed in a prim, that doesn't make much sense. If the Lab provides a way for legitimate users of the data to deal with their needs some other way, that's great; on balance, it's a win, though it's going to break thousands of items inworld.
The other three are simply LL telling TPVDs how the cow eats the cabbage.
The second bans the viewer tag system used by every TPV except for CoolVL. The stated reason is to protect the user's privacy, with an aside about people being bullied into switching. The politest term I can use to comment on that reasoning is that it's bullshit. What it's really about is LL not wanting people to know that their viewer is used by a minority of the user base, and that there are other viewers out there that are much more popular because they fail to suck.
The third is similar. There was some question as to whether turning on RLV was sufficient opt in to enable the @version reply message, which includes the name and version of the viewer; Oz said it would be. It also permits the use of the feature that shows whether a user is using Phoenix or Firestorm in the support groups, if they opt in (currently, that setting is opt-out). So yeah, they threw us a bone. Even so, the effect of these two is to greatly diminish the effects of the overwhelming majority of users running something other than the official viewer - which is exactly what LL wants. Their thinking, which they won't admit to but is blindingly obvious to anyone who looks, is that they hope to keep people from migrating away from their viewer.
The last is the worst. It prohibits TPVs from developing features for Second Life that won't instantly appear the same on the official viewer. Many of the features that users have requested most - multi-attach, avatar physics, parcel Windlight to name three - started out as features that TPVs introduced. They were all proposed to LL before they were introduced, and got shot down in flames; LL's use of the first two features came two years after they were introduced. The third doesn't exist yet in the official viewer, even though LL asked us not to introduce it before they did - and that was fifteen months ago.
Now they want us to submit proposals to them through the official process, then work with them to develop them in the official viewer, and only when the official viewer can show them can we roll them out in the TPV. Let's see...they can squash the feature entirely, after taking however long they damned well please to even look at the proposal; if they do accept it, you can't develop it in your own viewer, but only in the craptacular official viewer; and they can roll the feature out in the official viewer immediately when it's done, but we have to wait for that before rolling out our own.
This puts LL completely in control of our development cycle if we do have a new feature that's somehow survived the gauntlet. Worse, it's not symmetrical: the Lab can develop new things in secret, and spring them on an unsuspecting grid, leaving TPVs to catch up as best we can - and Oz said today they would continue doing that.
This limits TPVs to working in the UI, leaving actual improvements to the SL platform entirely at the mercy of LL. Tell me why we're supposed to be other than thoroughly pissed off at this?
The last paragraph is ripe with possibility for unintended consequences. Oz said that RLV would not be banned under that policy, and that parcel Windlight was getting a free pass - but only until LL got off its ass and released their version. I'm not holding my breath for that one. Look how long we've been waiting already. I'll also not believe that they'll do other than develop it in secret, without our participation, and then demand we remove it immediately, without giving us time to adapt the feature for our viewers, until it actually happens - and then only when it's a fait accompli. Oz also swears up and down that the process will be different. I'll believe that only when I see it, preferably several times.
No, we're not happy with the changes in the TPVP. We're stuck with them anyway. Fuck you too, LL.
02 February 2012
When it is acceptable for a TPV to borrow a feature from another viewer?
Oz Linden asked, in the email announcing the agenda for this week's Third Party Viewer Developers' meeting:
I'll preface my comments by saying that Phoenix and Firestorm aren't the first open source projects I've been involved in. I've been the manager of another project with several thousand users for 12 years now, and dealing with open source for longer than that.
The key to remember here is that the open source world is a gift economy, and it runs not on money, but on public credit for work. People work on open source software first and foremost to scratch their own itches, but they release their work in the expectation that they'll get credit for it. Eric Raymond explored this pretty thoroughly in his essay Homesteading the Noosphere. It's well worth a read.
I, personally, go far out of my way to ensure that whoever develops a feature gets full credit for it. I think that's true of the Firestorm team, even if it's not so much in other viewer development efforts. I think it should be. In the open source world, using someone else's feature without crediting them is as close to theft as there is.
The water gets murkier when LL enters the picture. After all, LL doesn't run on credit for its work. I can't speak to the actual motivations for their decision to open source the viewer in the first place, but for a corporation, it usually revolves around leveraging the open source community to improve their product through new code and bugfixes. The model certainly works, as many companies demonstrate every day.
Even so, it's not unreasonable for LL to expect credit for its work. There are things LL can do that no TPV can simply because they require server-side support, and those features can be pretty substantial. It would be unreasonable for Firestorm to claim credit for mesh, after all.
Credit isn't just in the eyes of the TPV developer community, though. We're a tiny, tiny minority of the users of SL. It also goes for the broader community of users, as well, especially since barely a third of them use LL-supplied viewers. They don't know the machinations behind the scenes that lead to the viewers they use. They just know what comes out with which new feature first.
We've been burned by this. Kirsten released her viewer with pie menu support before the release of Firestorm that had it. Guess who got credit for it in the public eye? Not Zi Ree, who wrote it, or Firestorm.
This led Jessica Lyon to propose an informal gentlemen's agreement among TPV developers and LL that nobody would jump the gun and release a new feature before the viewer in which it was developed was released without their permission. Most TPV developers signed on, as did LL. It seems to be working, though there's not a lot of data yet to say that for certain.
In general, I think it's inappropriate for one viewer to import a feature from another viewer unless it's in a publicly available release, or permission has been granted, and appropriate credit given - and not just in release notes or the like, but in the release announcement as well. "This release has feature X, developed by the Firestorm team", for example.
I know of no good way to formalize it, however. Any attempt will simply cause bureaucracy and annoyance, and not bind anyone who wouldn't already be willing to follow such a policy.
This discussion assumes that sharing flows both ways. There are some viewer development teams that have taken steps to limit or stop others from importing their features. One team licenses its viewer under the GPL, which prevents importing their code as a practical matter by any viewer that wishes to remain LGPL-licensed. (That team has other issues with legality, but that's outside the scope of this discussion.) Others simply don't commit the code to their public repository until it's ready for release. This defeats the purpose of a public repository in that it makes it much harder for people to trace the development history of the code until it's already in common use.
LL has changed its policy, too, and now will not make code for new features publicly available until they are ready for release in the official viewer. I believe this is a major mistake, as it both limits uptake of the feature - possibly to the point that it will never see significant uptake, as with media on a prim - and makes it more difficult for others to wring it out before it hits the grid. The stated reasons ring a bit hollow, but so far LL has been resistant to the idea of changing the policy. I hope that a resolution to the issue of credit will be enough inducement for it to be revisited.
This discussion applies only to code for new or improved features. Bugfixes are a separate issue. The overriding goal of every viewer developer is (or, at least, should be, IMAO) to improve the user's experience in Second Life. Bugs do not improve that experience; fixing them does.
We have waited, in the past, for bug fixes to be merged to viewer-development before releasing them ourselves. This put LL in control of the Firestorm release schedule, and when the bugfix took a back seat to new feature development, it left our users hanging. I'm not going to try to dictate LL's development priorities, but by the same token, I don't think it's fair for users to be left dealing with serious bugs while we wait for LL.
I believe that bug fixes are fair game, and should be shared widely, fully, and rapidly upon discovery and verification. This does not mean that credit should not be given, of course.
To sum up: I think the existing gentlemen's agreement for features is the right approach. I don't think there's any good way to enforce it, especially as a policy matter. Every honest, ethical viewer development team should have no trouble following it. Those that do not probably can't be stopped, except by reputation. Bugfixes are fair game whenever discovered and made publicly available in any form.
Some viewer developers have historically taken the position that any open source is automatically fair game to use at any time. This has sometimes lead to some changes being used either before the originator considered them ready for general use, or to other bad feelings.
I have asked that Linden Lab changes, even when in public repositories, not be used by TPVs before they are merged to viewer-development, and in the case of new features not before they are in a released viewer (though that differencer is normally very small).
- When is it appropriate to import a feature developed outside your viewer?
- Should TPVs explicitly get permission?
- Should there be a protocol for this?
I'll preface my comments by saying that Phoenix and Firestorm aren't the first open source projects I've been involved in. I've been the manager of another project with several thousand users for 12 years now, and dealing with open source for longer than that.
The key to remember here is that the open source world is a gift economy, and it runs not on money, but on public credit for work. People work on open source software first and foremost to scratch their own itches, but they release their work in the expectation that they'll get credit for it. Eric Raymond explored this pretty thoroughly in his essay Homesteading the Noosphere. It's well worth a read.
I, personally, go far out of my way to ensure that whoever develops a feature gets full credit for it. I think that's true of the Firestorm team, even if it's not so much in other viewer development efforts. I think it should be. In the open source world, using someone else's feature without crediting them is as close to theft as there is.
The water gets murkier when LL enters the picture. After all, LL doesn't run on credit for its work. I can't speak to the actual motivations for their decision to open source the viewer in the first place, but for a corporation, it usually revolves around leveraging the open source community to improve their product through new code and bugfixes. The model certainly works, as many companies demonstrate every day.
Even so, it's not unreasonable for LL to expect credit for its work. There are things LL can do that no TPV can simply because they require server-side support, and those features can be pretty substantial. It would be unreasonable for Firestorm to claim credit for mesh, after all.
Credit isn't just in the eyes of the TPV developer community, though. We're a tiny, tiny minority of the users of SL. It also goes for the broader community of users, as well, especially since barely a third of them use LL-supplied viewers. They don't know the machinations behind the scenes that lead to the viewers they use. They just know what comes out with which new feature first.
We've been burned by this. Kirsten released her viewer with pie menu support before the release of Firestorm that had it. Guess who got credit for it in the public eye? Not Zi Ree, who wrote it, or Firestorm.
This led Jessica Lyon to propose an informal gentlemen's agreement among TPV developers and LL that nobody would jump the gun and release a new feature before the viewer in which it was developed was released without their permission. Most TPV developers signed on, as did LL. It seems to be working, though there's not a lot of data yet to say that for certain.
In general, I think it's inappropriate for one viewer to import a feature from another viewer unless it's in a publicly available release, or permission has been granted, and appropriate credit given - and not just in release notes or the like, but in the release announcement as well. "This release has feature X, developed by the Firestorm team", for example.
I know of no good way to formalize it, however. Any attempt will simply cause bureaucracy and annoyance, and not bind anyone who wouldn't already be willing to follow such a policy.
This discussion assumes that sharing flows both ways. There are some viewer development teams that have taken steps to limit or stop others from importing their features. One team licenses its viewer under the GPL, which prevents importing their code as a practical matter by any viewer that wishes to remain LGPL-licensed. (That team has other issues with legality, but that's outside the scope of this discussion.) Others simply don't commit the code to their public repository until it's ready for release. This defeats the purpose of a public repository in that it makes it much harder for people to trace the development history of the code until it's already in common use.
LL has changed its policy, too, and now will not make code for new features publicly available until they are ready for release in the official viewer. I believe this is a major mistake, as it both limits uptake of the feature - possibly to the point that it will never see significant uptake, as with media on a prim - and makes it more difficult for others to wring it out before it hits the grid. The stated reasons ring a bit hollow, but so far LL has been resistant to the idea of changing the policy. I hope that a resolution to the issue of credit will be enough inducement for it to be revisited.
This discussion applies only to code for new or improved features. Bugfixes are a separate issue. The overriding goal of every viewer developer is (or, at least, should be, IMAO) to improve the user's experience in Second Life. Bugs do not improve that experience; fixing them does.
We have waited, in the past, for bug fixes to be merged to viewer-development before releasing them ourselves. This put LL in control of the Firestorm release schedule, and when the bugfix took a back seat to new feature development, it left our users hanging. I'm not going to try to dictate LL's development priorities, but by the same token, I don't think it's fair for users to be left dealing with serious bugs while we wait for LL.
I believe that bug fixes are fair game, and should be shared widely, fully, and rapidly upon discovery and verification. This does not mean that credit should not be given, of course.
To sum up: I think the existing gentlemen's agreement for features is the right approach. I don't think there's any good way to enforce it, especially as a policy matter. Every honest, ethical viewer development team should have no trouble following it. Those that do not probably can't be stopped, except by reputation. Bugfixes are fair game whenever discovered and made publicly available in any form.
25 December 2011
The game has changed
It's been quite a while since I've written a post. I've been keeping my head down working on Firestorm. But, as before, I'm annoyed to the point of feeling it's time I spoke out again.
There's been a lot of words, a lot of arguments, and a lot of hate and discontent over the Phoenix team's announcement that, with the mesh release, we have ended major development efforts on the Phoenix viewer.
Come on, people. This should be a surprise to exactly nobody.
We've been saying ever since the release of Phoenix 1185, months ago, that we were concentrating on Firestorm. We haven't changed our tune one bit, and we're not going to. The reasons haven't changed. The only thing that has changed is that we thought it wasn't going to be possible to put a mesh renderer in a version 1 codebase...and Henri Beauchamp proved us wrong.
I think Henri Beauchamp is a great guy, and an outstanding programmer. The same goes for Siana Gearz and Shyotl Kuhr of the Singularity viewer. They are clearly dedicated to keeping version 1 viewers alive, but I think they've bitten off more than they can chew, long-term.
All Second Life graphical viewers are based on one of the official Second Life viewers. Emerald 1632 was based on 1.23. Phoenix is based on Snowglobe 1.5, as are CoolVL and Singularity. Imprudence is based on Snowglobe 1.4. Firestorm is based, currently, on Second Life 3.1; we'll rebase it on 3.2 as part of the next release, most likely.
The problem here is that, as Linden Lab updates the viewer, and updates Second Life to add or change features, they're only updating one code base: the one Firestorm is built on. That means that anyone maintaining a viewer based on something else has to do a lot more work to incorporate those new changes, or else do without entirely. Since those changes often mean the difference between the viewer being able to do something critical - like load inventory from the server - and not, that means that the maintainer has to do that extra work.
Meanwhile, the Firestorm team can just import the code and update those parts of it that it's modified, a much easier task. Henri and Shyotl and Siana took the same amount of time to put mesh in their viewers as it took the Firestorm team to update from 2.5.2 to 3.1.
This problem will only get worse as time goes on, and the result can only be that the version 1-based viewers become more and more a tissue of hacks and scar tissue and duct tape and chewing gum.
Quite frankly, I've got better things to do with my time. I'm a Second Life user. Yes, I'm a viewer developer, and I've sunk an immense amount of time into the code. But the main reason I do it, as satisfying as it is to help the SL user community, is that I want a viewer that fails to suck.
Firestorm is that viewer. It will continue to be that viewer. At some point, version 1-based viewers will not be.
Make no mistake. At some point, sooner rather than later, LL will start turning off the services that version 1 viewers depend on. The version 1 search, profile, texture, and inventory interfaces all run on separate systems, with separate services behind them, and there's nothing in it for LL to provide those services forever. They soak up resources: administrator resources, power, network bandwidth, computer servers. LL has every reason in the world to want to turn them off.
Not only that, but LL wants - needs - to add function to the platform. They're not telling us about their plans. (A serious mistake; we can't adopt their new shiny if we don't know about it.) Even so, it's obvious that there's new stuff coming that will need viewer support. We have limited resources, and Henri, Siana, and Shyotl even more so. We can either dedicate those limited resources to moving with the platform and fixing those things that continue to annoy users, or else we can dedicate them to wrapping more duct tape and baling wire around the version 1 codebase.
I choose to concentrate on making the viewer fail to suck even more, rather than propping up a dying codebase.
If you use and enjoy Firestorm, great! We put an immense amount of work into it, and that's really all the thanks we need.
If you haven't tried Firestorm, all I ask is that you give it an honest evaluation. Put your (quite understandable; I share it too) loathing for the Viewer 2/3 interface aside. We've spent a year de-sucking it. Give it a good, honest try. Then, if you can't stick with it, tell us why - specifically, in detail.
If you refuse to consider using Firestorm because it's based on Viewer 2...well, quite frankly, I've got no more time for you. I'm busy making Firestorm even better, and I'm getting to the point where telling me that there's no way that Firestorm will ever be usable is nothing more to me than uninformed insulting blather. I know better. Compare Firestorm to Viewer 3.1 and you'll see just how much we've done. I can't stand Viewer 3 either. You know what? When I run Phoenix these days, it feels old and clunky.
Here it is. You'll have a choice at some point in the not too distant future. You can either switch to Viewer 3, switch to Firestorm, or get off of Second Life. You won't have the option of sticking to a version 1-based viewer.
As for us, we'll keep working on making Firestorm something you'll want to switch to when that day comes. That means we don't have resources to spend on Phoenix any more.
Phoenix was the best viewer on the grid for quite a while. Those days are past. Lead, follow, or get flattened by the stampede. Your choice.
There's been a lot of words, a lot of arguments, and a lot of hate and discontent over the Phoenix team's announcement that, with the mesh release, we have ended major development efforts on the Phoenix viewer.
Come on, people. This should be a surprise to exactly nobody.
We've been saying ever since the release of Phoenix 1185, months ago, that we were concentrating on Firestorm. We haven't changed our tune one bit, and we're not going to. The reasons haven't changed. The only thing that has changed is that we thought it wasn't going to be possible to put a mesh renderer in a version 1 codebase...and Henri Beauchamp proved us wrong.
I think Henri Beauchamp is a great guy, and an outstanding programmer. The same goes for Siana Gearz and Shyotl Kuhr of the Singularity viewer. They are clearly dedicated to keeping version 1 viewers alive, but I think they've bitten off more than they can chew, long-term.
All Second Life graphical viewers are based on one of the official Second Life viewers. Emerald 1632 was based on 1.23. Phoenix is based on Snowglobe 1.5, as are CoolVL and Singularity. Imprudence is based on Snowglobe 1.4. Firestorm is based, currently, on Second Life 3.1; we'll rebase it on 3.2 as part of the next release, most likely.
The problem here is that, as Linden Lab updates the viewer, and updates Second Life to add or change features, they're only updating one code base: the one Firestorm is built on. That means that anyone maintaining a viewer based on something else has to do a lot more work to incorporate those new changes, or else do without entirely. Since those changes often mean the difference between the viewer being able to do something critical - like load inventory from the server - and not, that means that the maintainer has to do that extra work.
Meanwhile, the Firestorm team can just import the code and update those parts of it that it's modified, a much easier task. Henri and Shyotl and Siana took the same amount of time to put mesh in their viewers as it took the Firestorm team to update from 2.5.2 to 3.1.
This problem will only get worse as time goes on, and the result can only be that the version 1-based viewers become more and more a tissue of hacks and scar tissue and duct tape and chewing gum.
Quite frankly, I've got better things to do with my time. I'm a Second Life user. Yes, I'm a viewer developer, and I've sunk an immense amount of time into the code. But the main reason I do it, as satisfying as it is to help the SL user community, is that I want a viewer that fails to suck.
Firestorm is that viewer. It will continue to be that viewer. At some point, version 1-based viewers will not be.
Make no mistake. At some point, sooner rather than later, LL will start turning off the services that version 1 viewers depend on. The version 1 search, profile, texture, and inventory interfaces all run on separate systems, with separate services behind them, and there's nothing in it for LL to provide those services forever. They soak up resources: administrator resources, power, network bandwidth, computer servers. LL has every reason in the world to want to turn them off.
Not only that, but LL wants - needs - to add function to the platform. They're not telling us about their plans. (A serious mistake; we can't adopt their new shiny if we don't know about it.) Even so, it's obvious that there's new stuff coming that will need viewer support. We have limited resources, and Henri, Siana, and Shyotl even more so. We can either dedicate those limited resources to moving with the platform and fixing those things that continue to annoy users, or else we can dedicate them to wrapping more duct tape and baling wire around the version 1 codebase.
I choose to concentrate on making the viewer fail to suck even more, rather than propping up a dying codebase.
If you use and enjoy Firestorm, great! We put an immense amount of work into it, and that's really all the thanks we need.
If you haven't tried Firestorm, all I ask is that you give it an honest evaluation. Put your (quite understandable; I share it too) loathing for the Viewer 2/3 interface aside. We've spent a year de-sucking it. Give it a good, honest try. Then, if you can't stick with it, tell us why - specifically, in detail.
If you refuse to consider using Firestorm because it's based on Viewer 2...well, quite frankly, I've got no more time for you. I'm busy making Firestorm even better, and I'm getting to the point where telling me that there's no way that Firestorm will ever be usable is nothing more to me than uninformed insulting blather. I know better. Compare Firestorm to Viewer 3.1 and you'll see just how much we've done. I can't stand Viewer 3 either. You know what? When I run Phoenix these days, it feels old and clunky.
Here it is. You'll have a choice at some point in the not too distant future. You can either switch to Viewer 3, switch to Firestorm, or get off of Second Life. You won't have the option of sticking to a version 1-based viewer.
As for us, we'll keep working on making Firestorm something you'll want to switch to when that day comes. That means we don't have resources to spend on Phoenix any more.
Phoenix was the best viewer on the grid for quite a while. Those days are past. Lead, follow, or get flattened by the stampede. Your choice.
Subscribe to:
Posts (Atom)