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.
No comments:
Post a Comment