There's a serious problem and very real threat when this goes Open Source. Usually what happens if it's a free "do whatever you want" open source license, is that some very competent but egoistical coders will want to outshine each other by not sharing their works, to avoid getting 'lumped in with the other coders', so they start branches to try and say "hey, my branch does sound better!", or "hey, my branch has nicer textures!".

You REALLY don't want that to happen. You want everyone to contribute to the same project to make Myst Online grow exponentially.

To do this, put it under a No-derivative-works Open Source license, which prevents offsprings that just hurt the project.

What do you think? I think we should have an open discussion about this before it goes open source, and Cyan has to carefully select an Open Source license that doesn't HURT their project. In my opinion, the only way to do that is to select a license that maintains the project INTEGRITY by preventing branching*. Something like the Apache webserver license, which allows anyone to contribute to the code but no offsprings to be created (it was the only logical license for them, because allowing branches would UNDOUBTEDLY confuse users and cause some branches to lag behind others on features and security fixes, as well as each and every branch being incompatible and having different strengths and weaknesses. so by forcing a no-derivative-works license, they have ONE good program "to rule them all" where every fix and improvement is contained, and it has worked out wonderfully for them, they are now the most popular webserver software).

Allowing branching would not only prevent great code changes from improving the MAIN project, it would also GREATLY HURT the user community, forcing separately developed, INCOMPATIBLE clients with different features and specifications, and people to say "hey, why are you playing Myst Online? Play Myst Online 2000, it's much better", killing off the main branch, instead of IMPROVING it.

I see absolutely no way for this to work WITHOUT selecting a license that prevents branches.

* (I'm not talking about feature test branches for testing of new ideas before adding it to the project, I mean when there are full derivative copies that try to outshine the real project, and not contribute their work to the real project).

Secondly, make sure there will be a system for validating/testing the current developments, to only release stable clients to the public, rather than putting the project in a perpetual, buggy "development build" (in laymans terms: buggy, prone to crashing, betas) state. It takes a lot of work to take a development build, test the hell out of it and determine that it's good enough to be deemed a "stable" release, but someone has to do it if this project is to survive the Open Source life. If the program keeps crashing, people will leave the game (although I'd rather call it a virtual community, I loved just walking around and voice chatting in it with people from around the world ).


- Jones

To be honest, the "Competent but egotistical coders" you mention will find their branches die quite quickly. If they're not willing to share their improvements, so their code can work with someone else's improvements and make a better client for the community as a whole, someone(s) else, perhaps not so competent, will come along and duplicate their work, but make it free and open. A closed branch of an open project may be popular for a little while, but soon it will be outpaced by other, open, branches, that do more and better, and will fall by the wayside.

Branching can be a disadvantage, but what generally happens in cases like that is that someone makes a "Best of all worlds" branch of all the branches, or imports the changes back into the original branch (See: XBMC and Boxee. Several of Boxee's improvements have been merged back into XBMC), keeping it up to date with the changes made in 3rd-party branches, and resolving conflicts where necessary.

So, yes. Branching can make things messy for users, but it's not likely to cause the death of the project. It also has the advantage that a developer can work on his private branch, refactoring, refining and improving as he goes, without having to worry about breaking changes coming in from another developer's work.

And, to be honest, Cyan has little time at the moment to oversee their repository to manage changes on it. They're down to a skeleton staff as it is, and don't have the time or resources to dedicate to managing a team of developers (Even 3rd party ones) and trying to keep them all in line. If Cyan allows branching now, then x months down the line, when they are back on their feet and able to take a more solid look at Uru again, they can look at all the differing branches that have cropped up and cherry-pick the best features from all of them to make their own definitive system. Which can then be sent down the line to the branches and updated.

This is what VCS' (Especially DVCS') do, it's what they're made for.

_________________
Avatar: Anaerin
Ki: 118686

Jones wrote:

... make sure there will be a system for validating/testing the current developments, to only release stable clients to the public, rather than putting the project in a perpetual, buggy "development build" (in laymans terms: buggy, prone to crashing, betas) state. It takes a lot of work to take a development build, test the hell out of it and determine that it's good enough to be deemed a "stable" release, but someone has to do it if this project is to survive the Open Source life. If the program keeps crashing, people will leave the game (although I'd rather call it a virtual community, I loved just walking around and voice chatting in it with people from around the world ).

Keep an eye on the OpenURU forums for information related to this. I've spent the last week working on a build "foundry" architecture and implementation (as far as I can go without details about the codebase) and am almost ready to do a writeup on it (along with how to do one if you're really determined). A continuous integration engine that monitors a (the) repository, notes changes, brings them into the foundry, builds the code (multiple OS bases, Windows and Ubuntu), and if that much succeeds, will execute any tests that are available for the codebase that can be run unattended. Builds a report that can be emailed and or browsed, and provides a download through HTTP of the resulting build artifacts.

[As I said, with as much info as has been released or rumored about so far. I may be in for a surprise about some dependency I don't have access to ]

Jones wrote:

Something like the Apache webserver license, which allows anyone to contribute to the code but no offsprings to be created

http://www.apache.org/licenses/LICENSE-2.0.txt

Quote:

4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions: [..]

"Offsprings", or more formally "derivative works" are allowed and encouraged with the Apache License.

Furthermore, I find your fear that "offsprings" will damage Uru's development unwarranted and puzzling, as I cannot think of any open source project where this has been a real issue.

_________________
Sören Nils 'chucker' Kuklau; KI number: 196082
MYSTcommunity & MYSTlore
I write soeren says. You don't.

Every open-source licence allows (and even encourages) branches and forks. A open-source licence that prohibits forks is not an open-source licence.

I think you are looking at the problem from a wrong perspective. Forks are not a problem. In fact, forks are necessary for a fan-run Uru. I would definitely not want a single entity controlling Uru, and I'm quite sure most people share this view.

ddfreyne wrote:

Every open-source licence allows (and even encourages) branches and forks. A open-source licence that prohibits forks is not an open-source licence.

I think you are looking at the problem from a wrong perspective. Forks are not a problem. In fact, forks are necessary for a fan-run Uru. I would definitely not want a single entity controlling Uru, and I'm quite sure most people share this view.

Interesting. I was sure their Apache license involved preventing derivative works, but it turns out I was not just a little off base, I was completely wrong. I wonder where all the forks are though? Or has everyone just decided to contribute to the main Apache webserver and not start their own forks?

What I meant by one single project is that you, Cyan, retain "overseer" control of the one project, allowing all users to use one client, one server, making sure that EVERYTHING is compatible with each other, clustering all players/avatars on one server platform to prevent a totally "dead space" scenario where you have 5 versions of Myst Online with 10 players in each, because of the complexity for people to select one of the projects and log onto that particular version, a choice that's going to require research and divides the userbase. It harms Myst Online, period. Any "beneficial separate developments" aren't going to make up for alienating a (likely significant) portion of the userbase that won't even get as far as choosing which "fork to play on".

Allowing the fracture of the Myst Online universe into separate projects is counter-productive to maintaining a working, solid "Myst Online", that's easy to find on the web, easy to install, adequately bugtested (focusing testing efforts on one project is easier than five), and just works (full compatibility with the main server software), evading the situation of multiple different search results where it's hard to even know which page to go to, the naming issues if multiple projects bear the Myst Online brand (again, how would you know which one to install?), and counterproductive community separation and alienation.

By having one project, your customers would not have the headache and confusion of 5 different versions of Myst Online (which would they choose? most people wouldn't know which one to go for, a majority of people are not that tech savvy and are lazy, they will spend 20 seconds on a page and if it looks too complicated they give up, and they definitely won't go and research all the pros and cons of each version to make a choice, although that being said, the current myst fans are probably smarter than most people, it's not exactly a brainless shooter game)

Conclusion: The most important aspect of maintaining a single, compatible project is that it retains the quality that allows it to bear the Myst "easy to find, just works" Online brand, because once you totally turn over the rights to make any number of secondary Myst projects, then you've lost that quality control, and you'll also have the aforementioned problem of each fork having strengths and weaknesses and incompatibility with each other. Allowing forks would only work (brand-wise) if the forks were to be prohibited from having anything to do with the Myst name; which would otherwise lead to serious identity crisis for the Myst Online brand. Wouldn't you want to protect your trademark and integrity of the high quality of the Myst brand? (If you allow everyone to use it, is the trademark even valid anymore? be sure to look into that if you treasure the Myst brand). As well as the aforementioned userbase alienation that happens if multiple projects bear the Myst Online name and claim superiority over one another. Keeping the brand, game identity and ease of use, and making the forks more like alternate games that use the Myst Online engine and can contribute their changes back to the MYST(tm ) project and vice versa would prevent likely scenarios where Myst Online becomes so fractured and torn between different alternate versions that it becomes more of a multiple-forked game engine than an actual game that people play, and therefore brand name protection is the healthiest solution..

with most of the open-source license what change you make must remain open-source as well to not do so whould break the
open-source licence

Ah. It seems I have been trolled. Please forgive my feeding of this particular bridge-dwelling nuisance.

_________________
Avatar: Anaerin
Ki: 118686

Quote:

I wonder where all the forks are though? Or has everyone just decided to contribute to the main Apache webserver and not start their own forks?

As far as I know, there aren't really any big Apache HTTPD forks. Everybody contributes back to the main project. This is likely because there is simply no need for forks; Apache likely accepts all improvements to their HTTPD.

To illustrate that forks can be useful, take Gaim/Pidgin for example. Gaim did have a fork at some point, gaim-vv, focusing purely on video and voice support. Pidgin currently has a fork named "Fun Pidgin", which adds features that the official Pidgin team seem to have rejected.

(Disclaimer: I don't know the exact details surrounding the start Fun Pidgin, and I am not familiar with the Apache HTTPD's development process, so what I said my not have been entirely correct).

Quote:

you, Cyan

I am not Cyan; I'm not even an employee but rather an intern. Also, be sure to read the bold line in my signature.

Quote:

Allowing the fracture of the Myst Online universe into separate projects is counter-productive [..]

The Uru community consists of several groups of people with different views on what Uru should be like. Some people prefer an unspoiled Uru; they want a Uru shard that contains only official content. Other people want progress; they'd join a shard where new ages are available. There will likely be a group that runs an "experimental" shard with new but unfinished ages among other content—basically a playground/sandbox for developers. Some people will likely run a "strictly-IC" shard as well.

There is the need to have multiple shards in order to accomodate different kinds of people. That's okay; having multiple shards may even work out better than having just one. Time will tell. However, there should be no need to run multiple "strictly-IC" shards. One shard to accomodate a single kind of players is enough.

There will be large shards and there will be small shards. One of these large shards will be semi-official, i.e. this will be the shard where new players arrive.

I hope this explains the reason why forks can be useful, and why there is really nothing to fear about having different shards. I realise this may all sound a bit vague still, but it will probably start making sense soon after Uru is opensourced.

If somebody really, REALLY wants to fork Uru off into something terrible, just let them. It doesn't affect the "core" Uru experience; which is most important.

ddfreyne has laid out some of the reasoning behind why the distributed source model is good here and elsewhere (in the OS Technical subforum), and I agree with all that.

There's a tendency to view forks as either "good, Cyan-abiding citizen works" or gateways into the worst x-rated tendencies of Sadville (as The Inquirer calls a certain large virtual world). Nobody ever seems to think that the source could be used in academia, or by other groups not wanting to join up to a company-run virtual world for a meeting place or game room (aside from terrorists, I mean!); this just smacks of censorship for censorship's sake.

Of course, let's employ the (rather silly, in my view) argument that "bad" forks would reflect badly on Cyan. I'm sure it's possible to create a license that has moral clauses or certain other restrictions on use. The closest thing I can think of in software would be MAME's license, but that's on a strictly legal and technical basis: Don't break the law with the source, and don't add closed-source stuff to ours (i.e. why Kaillera and multiplayer aren't a part of MAME officially).

Bottom line, those wacky, wily forksters won't bother you, so stretching your fingers complaining about their evil plots is a waste of time. At worst they just affect Cyan in some tangential fashion which rational people living in the modern world discount.

ddfreyne: It says "Cyan Employee" under your name.

Ed Oscuro wrote:

Nobody ever seems to think that the source could be used in academia, or by other groups not wanting to join up to a company-run virtual world for a meeting place or game room.

Wrong, that's exactly what I think it should be used for when it comes to secondary (fork) projects.

Again, for all the reasons laid out above, I think it's very important to keep "Myst Online" as one brand name, not: "Myst Online" (official), "Myst Online 2000", "Myst Online Redux", "Myst Online Worlds", "Myst Online Earth" (Alienating all those people that would not have the faintest clue where to go, fracturing the userbase, and having several incompatible projects that don't work with each other since major client changes require server changes as well, all in all leading to a lower userbase and more of a "niche" game/community that is hard to get into).

But most importantly:
A trademark lasts indefinitely, but you have to protect it (http://uspto.gov/main/trademarks.htm). Here's a simplified explanation of how trademark protection works, read it before responding. If the forks are not barred from using the name: "Myst Online", Cyan could lose their Myst trademark. That's a possibility that Cyan's lawyers must look into, and depending on what the lawyers say, add a clause that prohibits derivative works from using the Myst brand name. If you put all of those resources into building a brand, why throw it away?

So those dastardly academians in their white tower have been plotting all along to bring Cyan to its knees by forking it to death?! This must truly be a brilliant plan because I could never have conceived of it.

What is meant by a "fork" apparently needs clarifying. A source fork is not "Uru Deathball Ubermatch Baby Booting 1999 B.C." - it's simply source code that is different from what's in the official repository ddfreyne has postulated.

It would definitely be a fork to put in firearms ballistics modeling, but maybe somebody wants a better physics puzzle (there is a mining gun in one of the Ages, after all). It would also be a fork to change some feature of the KI and not have that rolled back in.

You'd need a fork, and possibly a lot of them, to create Jackboot John's Amazing 1940s Racing, but that's not the reason people will start making forks, at least not successful ones. Just look at a site like moddb.com to find lots of people who have ideas for things like the dreaded Uru Beach Shell Game Gaming, and they fall through because of the lack of expertise. Generally speaking, the people who are going to be programming and coding with the source are going to be oriented about features, and those features - for whatever good or ill they may cause - will be rather limited in scope individually.

The likely challenge for Uru's credibility would be people running some sort of server with their own subversive content on it...and all you have to do is avoid that server. Simple. They probably won't have the skill or enough culinary utensils to make it anything but a glorified chat room in big box Ages, after all (wow.wad comes to mind, lulz).

I'll happily concede that you've made a good point in saying that academic work (meetings mainly; or perhaps something of value to the social sciences) would be good, and I'm glad you're seeing outside the box there.

It also might interest you to know that my father was at the U.S. Patent and Trademark Office for some years, and still specializes in trademarks. The situation on needing to "protect" a trademark is not so dire as you suggest.

Opening a project's source and letting people develop new code for it does not entail signing away your trademark. Lots of semi-open projects have trademarks; Wikipedia (although I think they might not be properly identifying their mark all the time, but don't hold me to it) and MAME both allow people to write their own code (although neither, to my knowledge; is really an "open source" project: Wikipedia is "open content" and MAME isn't open source).

MAME is a good example in some ways, because while there are lots of custom builds, the particular license they use prohibits certain unsavory uses - it covers their behind while letting them do what they set out to do, despite the large and obvious hazards involved with the project.

But I suppose a tl;dr works just as well here. If somebody's being a jerk and making a bad fork, then it will go away. It won't bother you. Cyan will likely release their stuff with some kind of licensing that has certain clauses prohibiting certain kinds of use; it's up to them to include moral clauses or whatever. They have said it'll be open source, but that's really used as an umbrella term when maybe it shouldn't, because they could achieve the goals of open source without a pure open source license, if that makes sense.

And with that, tonight, I bid goodnight to the Senate.

The biggest issue with forking is incompatibility. If lots of people start creating ages that require various special experimental features of a custom version of the server or client, and those special features are either not pushed to a trunk version of the software (or, worse yet, can't be reconciled into the same trunk for some reason), then the end user may have to install multiple versions of the client in order to play, or the age creator may put in many hours of work centered around the experimental feature only to realize in the end that they'll have to set it up on some non-mainstream shard because the most popular shards are running incompatible server software.

I'm not saying don't fork, though - I'm saying either fork and keep it private, or fork with the full intention of re-merging your improvements in the near future.

Quote:

then the end user may have to install multiple versions of the client in order to play,

I'd say that multiple versions of the client are a no-no from the outset - servers yes, client no.

Yes, the client should be designed so it could connect to a variety of servers with a variety of content. Like a web browser to some extent. I don't have to get a new browser to look at CNN after looking at the DRC site.

_________________
-Whilyam