The following is an interview with the OpenUru.org team that introduced the open source CyanWorlds.com Engine to the world. The interview was done specially for the Guild of Messengers. The June 4, 2011 announcement of the special "Behind Open Source" issue and download of the issue, which also includes an interview with the Guild of Writers, can be found on the Guild of Messengers website here:
http://www.guildofmessengers.com/en/con ... ce-special
Special note: "Chogon" is Mark DeForest, CTO of Cyan Worlds.
Q: When did Cyan decide to begin working with OpenUru.org on Open Source?
Mac_Fife: Chogon first presented the decision to release the Open Source code through OpenUru.org during a conversation in mid-December last year, but there was no timescale set - it was the usual "Cyan soon"! As it was, it wasn't until late February that the sources actually became available.
Chogon: We have been thinking about open source for a long time and there was always something in the way. Legal issues, new projects, too few people, etc. But last fall I was talking to JW about MagiQuest Online stuff when the conversation turned to open source (again). I really wanted to get the ball rolling even if it was just the client and the plugins. But there were miscellaneous sticking points... Then independently a'moaca' approached JW about hosting the MOSS server software which turned out to be the key piece that brought everything together. And then wham-bam, things just started falling into place.
JWPlatt: I remained in contact with Mark (Chogon) fairly consistently after MagiQuest Online Chapter One was completed and the topic of open source would come up occasionally. Mac_Fife was even more consistently (and perhaps persistently) in contact with Mark in his role as moderator and spam investigator on the MOUL forms. Cyan was hard at work on their iPhone apps. After Riven was completed, Mark suggested they better get to it now if it were to ever happen. So after some internal Cyan discussion, he sent an email on December 17, 2010 to Rand, Tony and us at OpenUru.org laying out their plan to open source.
Rarified: I was a late arrival on the train. I found OpenUru.org right after the initial mention of open source for MOUL, and I'd corresponded with JW about ideas for things a community project would need, but I only heard it actually was going to happen in the first half of March. In hindsight, I probably could have speculated something was afoot because activity around OpenUru.org websites had increased since December.
Q: How involved was OpenUru.org in helping Cyan to achieve Open Source?
Chogon: What really helped Cyan was the working relationship that we already had with JW and Mac_Fife. With JW it was in conjunction with Creative Kingdoms and the MagiQuest Online project - there is definitely a difference when your livelihoods are so closely linked together. And of course, for *many* months I was talking to Mac every morning about what spam disruptor hit the forum the night before but we have worked with Mac on other things as well. So, because the "heads" of Cyan already had worked with these two before, it was much easier to move forward.
Mac_Fife: It's really Cyan's achievement - they did all the hard work to prepare the source files in the first place. We did provide some suggestions on the licensing models and acted as a "sounding board" during that decision process, but there was no real need for intense discussion between OpenUru.org and Cyan.
JWPlatt: Mark laid out three basic steps: 1) Release the sources to OpenUru.org, 2) Select the license, 3) Make the announcement. The rest was in the details of implementing it. Mark prepared the sources and discussed licensing with Tony Fryman, President, Cyan Worlds. Once that was done, and we received the sources, there was a bunch of back and forth on details. For example, Mark wanted to make sure the raw, original sources were kept available. Then MOSS came into the big picture a little later with a'moaca' and cjkelly1. Cyan gave us all the time to align our respective schedules, considering Mac_Fife and I had a lot of website and wiki work to get done, Rarified had to get Foundry ready and a'moaca' and cjkelly1 were completing MOSS and its impressive documentation. Rarified's work on the Foundry is amazing, by the way. I'd also like to add that since OpenUru.org was founded in 2008, Mac_Fife and Rarified have gone along on this open source train ride simply out sheer generosity of spirit and enthusiasm with no promise whatsoever of any success. They have professional and personal lives just like anyone else, yet found the time to volunteer their efforts - "above and beyond," as Rand wrote.
Rarified: Your question is posed in the past tense, so I must answer that I don't know much about interactions with Cyan as they were actually preparing the source release. What I was able to do during the wait was work on building an environment with a common set of hosted tools to make it easier for the community to collaborate on development. We eventually called this the Foundry. I worked on equipping the Foundry with the ability to automatically build the open source version of MOULa as soon as changes were pushed to the OpenUru repository. I had hoped that this shared set of tools and processes would be attractive both to the MOULa community, making it easier for non-technical people to have access to current versions of the game, as well as to Cyan by having a well known place for collaboration and sharing new (and fixed) elements of the open source game. Whether this had any influence on Cyan's progress toward open source only Cyan can say.
Q: Cyan has put the focus on OpenUru.org by trusting the site with the open source release. How do you plan on moving forward with the materials you have been given?
Mac_Fife: Turn that round - How do YOU plan on moving forward with the materials? Cyan have given them to the community as a whole, not just OpenUru.org: We're the conduit for delivery, but now up it's up to everyone to contribute.
JWPlatt: Our plan has always has been to provide the resources for everyone to develop their own projects and contribute to open source. Our mission is to support the effort to continue development of the CyanWorlds.com Engine and anything related to it on the path to MOULa. We are hosting Cyan's open source project, but it is up to everyone to pitch in to realize its potential. This could be original art, music, content or whatever new innovations come about. But even those who do not do those things and just like to play know what they enjoy. So there's plenty of room for everyone to get involved, for example, by contributing to discussion, reporting bugs, or suggesting new features.
Rarified: I'll echo Mac_Fife and JW's responses, but add that I see my role as a steward of the open source components. The Foundry is a server that is a work in progress. We were able to get the repositories, the bugtracking software, and source code browsing and review tools in place prior to the announcement. The infrastructure to build the source code into programs you can run on your computers exists, but still needs to be configured to monitor the repositories and perform the build tasks. We're trying different processes for accepting contributions from individuals or groups which use experienced members of the community to review those contributions and look for obvious mistakes or unexpected behavior. Looking at a longer timeframe, I'd like to see if we can build a set of automated tests to apply to newly built versions of the games. We also could use the Foundry to make tools available that people may not have access to themselves. We might be able to acquire rights to use rendering tools such as 3d Max in a shared environment were people can submit their models and pick their finished models up later from the Foundry. As you can see, a lot of this is "behind the curtain" work that aren't necessarily changes to MOULa sources, but are needed to build the game and ages that the game can use.
Q: Tell us about MOSS and the challenges of that project.
a'moaca': MOSS started out as a smaller project both to let me "keep" the MOUL ages, and to see what the interesting parts really are in a server project. It was personal, and for fun. MOSS's goals changed a bit over time, eventually becoming a serious multiplayer server project.
a'moaca': I'd say the two main challenges were the reverse engineering, and testing. For the reverse engineering, I started the project with a great deal of knowledge from past Uru work, but there's always some data you forgot or didn't know you needed to collect, or some data you just can't collect. Sometimes we had to just write something and see what happened when you put it all together and tried to play the game. We got stuck for months on a bug where avatars would be invisible to others, but in a very asymmetric way. Even so, testing also sometimes proved to be a big challenge. It's not very glamorous, but it's the honest truth that even figuring out what to test, and then how, and then doing it, isn't always easy.
a'moaca': I suppose a final challenge, and maybe the biggest one of all, isn't a technical one -- it's sticking with a big project for a long time, and doing the less interesting parts instead of stopping, especially when there is always something else you can spend time on.
Chogon: The first time I met a'moaca' (I know this was supposed to be about MOSS servers but...) was at one of the first Mysteriums in Spokane. I had to pry her and cjkelly away from a wayward printer at Cyan that they were going to set right. Not that I didn't think they couldn't fix it, it just didn't seem right that fans on vacation should be working on such stuff. But of course, digging deep into the internals of things is the way of a'moaca' and cjkelly. They have helped me and Cyan numerous times including that dodgy network problem with the GameTap MOUL service (and of course, Mac was involved as well, heh). So, it shouldn't be so surprising that they created the MOSS server but it is still amazing to me, especially a'moaca's talents.
JWPlatt: MOSS was an incredible gift. The original plan just had us releasing the CyanWorlds.com Engine with the client and plugin. Cyan needs to do more work on the server sources, so they were not available. And we did not even plan to make the client buildable so it could actually be used out of the gate. But a'moaca' independently contacted us about hosting MOSS not long after we started our open source release plans. So now We had a working MOUL server and both a'moaca' and cjkelly1 aboard to make the client work. We suddenly had the capacity to offer a complete MOUL shard. It was an amazing achievement for them and a real treat for the community compared to our more modest, original plan. And it took the pressure off Cyan to release their server sources. It's great when you can do something to make things easier for someone else.
Q: Are there any bugs or pieces of code that need to be worked on with the current release of the engine?
Chogon: Bugs! What bugs? Oooooooh. Those bugs.
Mac_Fife: Of course there are. In stripping out the code that Cyan couldn't redistribute and substituting alternative libraries, some "emergent properties" have arisen, not least several oddities with PhysX. That's on top of things that might already have been in Cyan's build of the software. We feel that the first thing that needs to be done is to try to get back to as near as possible a functional match to Cyan's build, so we've got a comparable baseline to work on. Rushing to try to add new features before getting the fundamentals working properly would just create more debug work in the future.
a'moaca': "Yes." I keep hoping someone will come along and make it so public keys aren't compiled in, and shards can be accessed using the same client, just with different keys stored in files or something. But this is just the tip of what could be done, and obviously coming from my server-centric view. I just mention it because I think reducing barriers to people using the CWE client will make it easier to do more interesting things later.
JWPlatt: There's a lot to do. The third party SDKs Cyan had to remove for open source release need to be replaced. The 3ds Max plugin needs to be able to get built with the version 7 SDK somehow. The client that you run on your computer is only the external release. The internal builds used for testing still need work. People have been reporting bugs for years. Many of them still exist - probably a lot of your "favorites" like broken JPGs or not being able to sit and chat at the same time. Wouldn't they be nice to fix? But we would prefer to concentrate on restoring functionality before getting to the pesky bugs people love to hate. That's not to say some of the little things can't be fixed on the way. They just shouldn't become a distraction from higher priorities.
Rarified: I would like to add that we set up the bugtracking tools for this purpose. I hope that people who have encountered bugs will visit the OpenUru bugtracker (called JIRA), and enter descriptions of the problems they've seen. Unless it's recorded somewhere you can't be sure if you were the only person to encounter a bug, or see if others have seen it. And it is a lot easier for developers to browse the bug database and see if what they're working on has already fixed a bug, or could lead to a fix. Again the effectiveness of this depends on getting people involved: submitting bugs, looking for bugs to fix, looking to test fixes.
Q: Will OpenUru.org pursue a working relationship with the GoW?
Mac_Fife: It's more the case that OpenUru.org provides tools that we hope will assist developers, age builders, artists, etc., whatever allegiances they may or may not have. We hope that as many people as possible will make use of these facilities - it was what OpenUru.org was originally created for.
JWPlatt: This really is a question that deserves a larger scope. There's a world of people out there who might want to be involved. We will pursue or invite working relationships with any group of developers or any individual developer. Any venture like this is going to work better and reap more rewards when everyone shares what they do. That's open source. Open source is a big world and we hope to attract lots of people, many of whom we've probably never heard of yet. If you'd like to read what we have been reading during our preparations, take a look at Karl Fogel's free book, "Producing Open Source Software" by downloading it from http://producingoss.com.
Rarified: To some degree I believe we already are in a working relationship with GoW. A key tenet of open source is the sharing of contributions. I hope that the GoW will be happy to let us incorporate changes and improvements that they have spent a long time thinking about and now are able to realize. There are some differences in our thinking about how to perform software development, but that doesn't preclude each benefitting from the strengths of the other (and there are more parties to the MOULa community than just GoW and OpenUru). And I expect that over time OpenUru will have some assets and resources that other groups and individuals will consider valuable and we'd be pleased in that case to contribute back.
cjkelly: I wish them the best of luck in achieving their goals (ripping out and replacing PhysX is a big task - although PhysX runs on Linux, so maybe not strictly needed). I hope that if they have a need for resources OpenUru.org can provide, that they will consider stopping by.
Q: Does OpenUru feel that it has achieved a successful open source project that can receive positive contribution from community?
Mac_Fife: "Success" suggests project completion and we're only at the beginning of this project, not the end. You could say that yes, we feel we successfully helped Cyan to launch the Open Source project and get the CyanWorlds.com Engine out to the public. As for receiving positive contributions, we're already starting to see some community efforts coming back in through the repositories.
JWPlatt: We have successfully helped Cyan Worlds to launch their code with support for a fully operable shard and the resources and tools to develop that further. Positive contributions are essential to its ultimate success. To that end, we want to provide a friendly, but professional atmosphere. When I say "we," I mean anyone who wants to contribute and eventually gain a place of merit among the community. Those of us who launched the effort will enjoy seeing the community run the project.
Rarified: Agreement -- your question implies we've arrived at some end state. I think we have helped with the launch of the open source project. We've tried to anticipate the future needs of a growing community and put in place initial solutions to those needs. But the real success will be determined by keeping the project going, growing, and exploring. Nothing OpenUru has offered so far should be considered a final word on how to progress. Progress and planning will come from involvement of passionate community members who are willing to contribute to and help define goals to work toward. And when those goals are met, I'm sure there will be no shortage of new ones to start addressing. It doesn't sound like an ending has been written, yet.
Q: Has the OpenUru team thought about new features that can be added to improve engine?
Mac_Fife: During the two or three years that OpenUru.org has been running there have been many interesting suggestions made, but possibly the most recurring question we see is "Where is the native Mac/Linux version?". That's a relatively big task, because cross platform support means removing dependencies on things like PhysX and DirectX. PhysX is a particular issue because replacing that could result in the need to make adjustments in the PRP files for ages. That's maybe not such a big issue for fan ages but as there is no license that permits modifying Cyan's ages then that could break compatibility with MOULa.
JWPlatt: We've all played the game countless times, know what we like, and know some of the things we want to see happen. Personally, my pet peeves are corrupt JPGs, a too-grabby windowed mode, num lock beyond my control, not being able to sit down and chat at the same time for goodness sake, and the lack of a fully automated Lake Project for the pellets. "Bevin" was one of those pet peeves, but congrats to vidkid7 on his success there already! But it really does not matter what the original team's fondest wishes are. We're hoping that everyone can join in to determine the things that most people want.
Rarified: I'd like to take some serious time to wander the cavern again (I haven't had the time to visit "countless times" I'm afraid :)). I don't have something specific in-character right now I really need fixed. But I am a bit of a networking geek. I think I'd enjoy participating in efforts to explore alternative communication topologies between clients and servers to increase the scale of the game (meaning you could have more than 50 people in an instance and not see much lag). But I'm talking about changes that would be incompatible with MOULa as it exists today, and it's a little premature to talk about how or when to work on large scale changes to the "official" game. That's not our decision, in any case. We can only offer ideas or examples and see if they are compelling.
Q: There seem to be a lot of viable suggestions in the "Getting the Ball Rolling" thread on your forums. What suggestions did you like? What suggestions did you not like? How do you plan on implementing the suggestions you found favorable?
Mac_Fife: There has been a lot of discussion there about "keeping the barriers low" for any developers making contributions: That's fair comment and we possibly have our barriers set a little high right now. But we're all people with long standing experience of software development in professional environments and recognize the value and need for "process" to maintain integrity. It's about getting the balance right and we're not there yet. We need to get people in place to man the barriers and ensure that they're set right, but it's bit of a chicken and egg situation while we get started. We would have loved to have got some people on board for this prior to the Open Source release, but we had to keep things on a "need to know" basis until Cyan were ready to announce.
JWPlatt: We like the suggestions about reviews. We're a believer. We liked the suggestions on the MOUL forums, most memorably by Denis, but also by others when open source was originally announced in 2008 that we should use a Mercurial repository to consider this very distributed community. We're a believer. We like the suggestion about hosting a mirror repository. That was actually on my original ToDo list before release. We like the criticism that we weren't keeping the barriers low enough at the start. If you'll read the book by Karl Fogel I mentioned earlier, you'll see we take that seriously. We will address all these things now and in the future as the come up. Any criticisms that also come with solutions and offers of participation are even better.
Q: Are there any restrictions that will be placed on the development repository?
Mac_Fife: Simply for the sake of sanity, there needs to be some restriction on who has commit access to the repository, and we're in the process of trying to fast track people into position for that.
JWPlatt: There was originally a requirement to have an account on OpenUru.org's Foundry to pull (download) the software. We could not predict interest in a project as large in scope as one by Cyan Worlds, so it was prudent to prepare for significant demand. Remember what happened when MOULa first came up? Since then, we have been moving toward anonymous access as things settle and we are able to make those adjustments. At the moment, anonymous access is provided with guest access (user guest, password guest). There will be a review process by peers for peers before changes make it into the main trunk. All qualified (by peers and the community) developers have access to the repository to commit their own changesets and branches for review. Or we will sync up to their work (being open source and all) and pull it in. Commit access, meaning those who can make changes, to the main trunk will be earned from the community of developers by the merits of their work, probably some participation in constructive reviews of their peers, and overall community participation. How smaller, intimate development groups manage their own projects before it gets to the main trunk - the stable software to be used for your own shards or MOULa - is left completely up to them until their work is reviewed and ready for the main trunk. The Foundry at OpenUru.org can point its tools to any remote repository, so all our resources and tools are available to anyone, anywhere.
Rarified: Don't break it! How we manage to accomplish that will be a matter of experimenting with different processes. I expect that there will be a drop-box repository branch that will be very open for developers to push a change to so it can be shared, whenever they choose. But based on the last few decades of experience in software engineering, we would benefit from some form of review for those changes to make their way toward being in the "current offering" state. By the way, reviewing changes is not something only for "experienced developers", whatever that means. It's a real opportunity to learn by reading why a change was needed, where in the source code the change had to be applied, and how the change works. The review pages are available for anyone to browse, so you can see comments by others on source changes, think about the reasoning behind them. Even question them if you disagree with a conclusion or implementation. Take advantage of the opportunity.
Chogon: The only one restriction that I want is to have a branch (default) to be what is on (or completely compatible with) MOULa. Other branches can go as wild as the wind but I want one branch where people can go and get something that will be compatible with the MOULa service - new fan created content and code changes created from this branch will have a far better chance of getting into MOULa, which is something I dearly want to see!
Q: How will Cyan’s eventual release of the MOULa server code impact the work that has already been done to create MOSS? Will there be any advancements made as a result? How will the MOSS project work to successfully use Cyan’s server code?
a'moaca': The release of the MOULa server code would mean there is another open source server implementation. I'm not sure how that could impact what was done in the past. Certainly the server code would reveal new things about how MOSS ought to work. For example, I'd love to know what algorithm is used to filter kickable messages (e.g., cones). Everyone in the age tells the server what *they* think that cone should do, and the server has to in turn pick something to tell everyone else is the final answer. MOSS does it, but not as well as Cyan's server. So MOSS could definitely learn a thing or two.
a'moaca': What I don't think is likely to be worth the effort is trying to merge the two in a single shard. Because we can't see what goes on server-side, there's no way MOSS handles clustering servers in a shard the same way the MOUL server does. And for bigger ideas of being able to run some kind of multi-shard system where you can move between shards... well, I rather doubt the MOUL server has any support for an inter-shard system either. Why would Cyan write that when the plan was for one Uru? So if people wanted that, we'd have to invent a way to make that happen, and implement it in both, and then shards running on either server would be able to work together in that way.
Chogon: That is such a long ways off it is hard to think about. Actually, I can imagine things being released that would tie the MOSS servers and the MOULa service together. Such as a way for the MOSS server to authenticate users against the MOULa accounts. That way everyone just needs to maintain one account across many servers. Or be able to link from one age instance running in a game server on MOULa to an age instance that is running in a game server on a MOSS server - so it would be less about shards and more like clouds of age instances running all over the world. Maybe a little far fetched but with a bit of work it could be doable with the right cooperation between the two server types.
Mac_Fife: Cyan have indicated that there are complications in getting their server code ready for release, and that it'll take some time, so a'moaca's MOSS came along at a very opportune moment. MOSS and the MOULa server code are two completely separate implementations of the same application, and each runs in a different environment: MOULa needs Windows Server 2003 and an Oracle database, MOSS runs on Linux with a PostgreSQL database, so the codebases aren't really comparable except in overall function.
cjkelly: PostgreSQL was chosen for MOSS because seemed that it had better support for stored procedures and LISTEN/NOTIFY (even though we currently do not use LISTEN/NOTIFY). The pl/pgsql language is very close to Oracle. When Cyan server sources are available, it should be a simple matter to adapt their stored procedures for MOSS, if it is determined that such a thing is desired. I believe there are even guides about such a thing floating around on the internet.
JWPlatt: We don't expect the MOULa server code to be released any time soon. With MOSS, there is also less pressure for Cyan to release their server sources. MOSS will certainly advance with participation, but perhaps only within its own infrastructure at first. Maybe things like Mark's description of subshards in the past (he called them front-end shards, but, well, I like subshards better - heh) are needed. Or support of additional databases like MySQL and Oracle. Some advancements may involve the protocol. The protocol between your client and the server is what MOULa and MOSS have in common. It's what makes them compatible even though the actual programming languages and platforms are different. Advancement to that will require compatibility on both ends. How that would work remains to be seen.
Q: What benefits are there to these new tools and how will they impact the age creation process?
a'moaca': The big answer is that people will now be able to test and play their new ages in the newer (MOUL-era) client, and in a multiplayer setting. This is a natural effect of the primarily single-player Path of the Shell-based testing done earlier, but there tend to be multiplayer problems in new ages. Even Cyan has multiplayer problems in some of their ages! Some of the work I did on the Alcugs server years ago was aimed at improving multiplayer support so that new ages could be made to work correctly multiplayer. So MOSS will hopefully help with that goal too.
a'moaca': MOSS also tries to help out with age testing. For example, to change an age's SDL file in Alcugs, you had to shut the server down and I hated that, so with MOSS, you don't have to shut down the server. Another thing MOSS lets you do is give different Python to different account holders. In theory, this way you can restrict who has the code or even access to new ages while they're being tested. But I think we will see a move away from getting precompiled Python from the server (which I think is a good move overall) -- but when I wrote the feature for MOSS I had no idea we would be able to do that so easily. :)
a'moaca': The nice thing about the open source is if we need either the client or server to change to ease age creation, in ways not already present... we can do it!
Mac_Fife: Probably the greatest benefit is the relative ease of testing your ages against a MOUL compatible server.
JWPlatt: The benefits are clear: New content now has a path to MOULa for all the acclaim, notoriety, oohs and ahhs inherent in getting your work seen on Cyan Worlds' shard. Or you can build your own shards to publicly showcase your own work and that of friends. This "reconstruction" is what everyone has been waiting for since... forever.
Rarified: I'd like to mention once more that the Foundry exists so you don't have to be an expert in every aspect of building the whole game. If you're an age developer, we hope we can offer a server and client already built that you can use to test your age. If you want to explore age building, maybe all you want to change is a small script describing how something looks or acts. We might be able to set up a process at the Foundry to build a game with just that one small change, and then that version of the game would be made available for you to download. Likewise for small changes to the game source code. Such things may be a ways off in time (or never happen if we don't hear that such things would be useful), but they're possible.
Q: How does OpenUru as a whole plan to adapt to the needs of the community? Do you feel that you have done that already?
Mac_Fife: It's a process of continual improvement. Right from the start we've sought to find out what tools people needed from OpenUru.org, and tried to provide them, often putting up alternatives for evaluation. We set up the Mercurial repository for CWE because it's what people were telling us was best tool for a project that might have many forks and branches. We're seeing people starting to ask for a "server in a box" type of solution to setting up a shard. It's something we had in mind a long time ago, but now we're looking at that more seriously as something we could provide.
JWPlatt: We provide the community with resources and tools it needs to have a voice that everyone can hear to achieve the long-awaited dream of creating their own content on Cyan's platform. I'd like to emphasize that we are all Open Uru. OpenUru.org can be anyone who participates and contributes, not just "they." What we've done is a start. It needs your (the collective 'your') participation. If past demand is any indication, there will be a lot of people who want to participate and we'll make every effort to give them that chance. Most of the changes made to OpenUru.org are derived from public suggestions. For example, I remember a particular post from Sophia in 2008 who plainly said our site lacked coherence and was difficult to navigate. We built those improvements into our open source release schedule, providing much better coherence and navigation. We don't assume anything is "done." We'll continue to take criticism and suggestions and try to channel that into something that works for as many people as possible.
Rarified: The same things can be said about processes. We're just trying our first best guess on how to steer things. Tell us if you see icebergs in our path and we'll try to maneuver around them. We need to hear from the active members of the community, and we need those members to listen as we accumulate sometimes conflicting needs and make a choice.
Q: So now that all the work has been accomplished it is up to the community to move forward with this new expanse of opportunity. Has there been any comments made by members of the community that have really impressed you as far as ambition goes?
Mac_Fife: There are a couple of people who've been enthusiastically getting to grips with the 3ds Max plugin, which is something we didn't have time to look at too much before the official release. Taking a slightly different view on "ambition", it's been good to see some relatively inexperienced people taking the MOSS sources and managing to build their own server. So, as well as getting open source out to the masses this might be drawing more people into an active interest in the development side of things.
JWPlatt: I know what you're asking, but I'd leave out so many people. I'll mention just one: Mark DeForest (Chogon). He has been all along a champion of making fan content a reality and getting open source done and out there. Rand has also wanted to be "chugging down that open source track," but it was up to Mark to implement it and deal with all of us crazy-mad Uru zealots with amazing tolerance and grace. I admire and aspire to his generosity and kindness not only in this community but in other completely unrelated things as well. I don't know how he finds the time. If there's anyone to thank for their ambition to see all this realized and for things to come, it's Mark DeForest.
Rarified: I also will mention Mark. Although I still have very limited contact directly with him, I'm starting to learn how he approaches problems and balances the incredibly demanding position of a CTO at a company with the needs of a passionate user base which can never be completely satisfied. I'm not sure how he does it. But since you mentioned ambition, I'll have to bite and acknowledge the extraordinary energy and ambitions of the GoW development group. They've spent a lot of time learning how the game works from inside out, and in the course of that learning have discovered things that can be fixed, improved, or added outright. They have a vision they want to realize for the future of MOULa. But it is only one of perhaps many different visions. I look forward to seeing their work become a part of what the community as a whole wants and can make happen.
Community News & OpenUru.org Announcements
Moderator: OpenUru.org Moderators
1 post • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest