<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2995" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Mark</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thank you. This is the best bit of information yet. Its real its timely and I assume its accurate.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I'll use this.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Brendyn</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV><FONT face=Arial>Brendyn Hancock</FONT></DIV>
<DIV><FONT face=Arial size=1>IT Manager</FONT></DIV>
<DIV><FONT face=Arial size=1><A href="mailto:bhancock@nagle.sale.catholic.edu.au">bhancock@nagle.sale.catholic.edu.au</A></FONT></DIV>
<DIV><FONT face=Arial>---------------------------------------------</FONT></DIV>
<DIV><FONT face=Arial><STRONG>Nagle College</STRONG></FONT></DIV>
<DIV><FONT face=Arial>5152 6122</FONT></DIV>
<DIV><FONT face=Arial>Bairnsdale VIC 3875 
<P><FONT face=SansSerif>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ </FONT></P>
<P><FONT face=SansSerif>Important - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of Nagle College, Bairnsdale. </FONT></P></FONT></DIV><BR><BR>&gt;&gt;&gt; kel@mckinnonsc.vic.edu.au 29/11/2006 11:19 am &gt;&gt;&gt;<BR><BR>"OpenTTD" (http://openttd.org) is an open source reverse-engineered <BR>version of a much-loved game (Transport Tycoon) that is now 10 years <BR>old, and had to be rewritten for it to continue running under Windows.<BR><BR>A virtual (volunteer) global team works on its development.&nbsp; I asked its <BR>former lead developer a few questions about the virtual team experience.<BR><BR>Maybe some of his observations may be of interest...<BR><BR>---<BR><BR>Sure we can help you out with those questions. Let me start off with<BR>just answering the ones you asked:<BR><BR>&gt;&gt; &gt;&gt; Do you, for example, use instant messaging, email, videoconferencing?<BR><BR>Our main ways of communication are IRC and a mailing list. Where the <BR>last one<BR>is introduced last year, but this isn't working really well. Mostly<BR>because of the delay between question and answers. So it comes down to<BR>IRC for 95% of the time.<BR><BR>&gt;&gt; &gt;&gt; Do you have team rules about communication e.g. filenaming, file<BR>handling, versioning?&nbsp; Are the rules written down anywhere?<BR><BR>For file handling and versioning we use SVN (Subversion). We have a<BR>coding style and a set way of how to make commit-messages and stuff at<BR>our wiki (http://wiki.openttd.org/). It has to be said that some<BR>developers refuse to use any of them. More about this later.<BR><BR>&gt;&gt; &gt;&gt; Do you have a dedicated forum for managing the team?<BR><BR>No. As said before, we decided that anything should be open and public,<BR>free for everyone to join. Everyone follows the same set of rules. So<BR>there is no real need to have a forum for managing the team. The<BR>communication between the developers most of the time is plenty anyway.<BR>From time to time this goes wrong, which results in an explosion of<BR>emotions, but I guess that can't be avoided in any way to use.<BR><BR>&gt;&gt; &gt;&gt; How do you exchange very large files (e.g. CD-sized)?<BR><BR>We don't have such large files. The biggest file OpenTTD related is 15<BR>MB, which is a full debug version of the openttd executable. As most<BR>people have ADSL or faster, this never has been a problem. The few<BR>people still on 56k6 rarely care about such files or have the time to<BR>wait for it.<BR><BR>&gt;&gt; &gt;&gt; What problems arise from working virtually rather than face to face?<BR><BR>The main problem we have, is that you can't penalise anyone or anything.<BR>You can't force someone to do something. As said before, it happens that<BR>some developers do not obey a commit-style or code-style. In the worst<BR>case we can remove the commit-rights, but this only makes people more<BR>p***ed off. Other then telling those persons over and over and over<BR>again, there are no options. This is, in my opinion, one of the worst<BR>problems we face.<BR><BR>Of course there are many other problems. You can't read someone his face<BR>over the Internet. Therefore it happens from time to time that<BR>communication is misread. This mostly results in some hard words going<BR>from one end to the other, after which is established it was a misread.<BR>Of course mostly the damage is done at that stage. But, this is all very<BR>common for an Internet managed project.<BR><BR>&gt;&gt; &gt;&gt; What benefits are there to working virtually?<BR><BR>We have people from all over the world. From Canada to Germany, although<BR>most of the developers are from The Netherlands for some unknown reason.<BR>This, I am sure, is just a coincidence. That is one of the biggest<BR>benefits. You can have the biggest minds working for your project,<BR>without moving them to one place on the world.<BR>Others are that you can work in your own time in your own way. For<BR>example, I like loud music, where I know some others like absolute silence.<BR><BR><BR>To answer what kind of hardware, software and procedures we use:<BR><BR>Software: we use bug-tracking software to keep track of bugs and patches<BR>of users. We use a todo-tracker internally to keep track of things we<BR>think should be done. For the rest we use a wiki to put documentation<BR>on, make use of doxygen to comment our code, and use a forum to stay in<BR>touch with OpenTTD gamers.<BR><BR>Hardware: nowadays we managed to centralize most of the stuff. We have 2<BR>major places where stuff is located: in .nl and in .hu. Stuff is<BR>balanced between those 2 places. Slowly we are in the process of making<BR>mirrors, as the project is growing bigger and bigger.<BR><BR>Procedures: there are a few set procedures how to do what. Lately I<BR>focused most of my time to make a few more. Then I talk about things<BR>like: how to make a release, how to make a nightly, how to make a<BR>bundle, how to make a... This isn't really documented yet, but this is<BR>slowly being done.<BR><BR>Back in 2003, only 'ludde' ran the project (yes, this project is just 3<BR>years old, almost 4). He knew how to do stuff, but he was the only one<BR>who did. When ludde left, others already joined and were taking over<BR>stuff. Everything was not really centralised and was poor of<BR>communication.<BR><BR>Most of my and MiHaMiX (we both manage all hardware and<BR>software) efforts went in the last 2 years in making this better and<BR>better. Too bad most of the 'old' people don't like those improvements,<BR>and so the deploy of it goes slow. The argument mostly is: "it always<BR>worked this way, so why change it?". Still, slowly we manage to put in<BR>new stuff. To give some examples:<BR>In the old days the whole project was around SourceForge. SourceForge is<BR>nice, till a certain point. So, we no longer use the SF bug-tracker, as<BR>it just sucks (sorry, no other words for it). We now distribute files<BR>via Torrent too, and soon a non-SF http mirror will be available.<BR><BR>Other things that are planned to do, to improve the coding-speed mostly,<BR>is to have a site where you can upload a patch, which gets compiled<BR>automatically. The next step will be that users can do this, and post<BR>their changes on the web. Users can then post their comments on the<BR>changes, so developers know if it is a good change or not. This to<BR>improve the gap between users and developers.<BR><BR>Anyway, I have no idea if any of what I said is anything you wanted to<BR>know. If you have any other questions we are more then happy to help you<BR>out. As you might have read between the lines in the above, the current<BR>communication is far from optimal in the current situation. For sure we<BR>work on that every day, but it is hard to manage a team over the<BR>Internet. Mostly because people can unexpectedly disappear, as we<BR>noticed a few times in the past.<BR><BR>With kind regards,<BR><BR>Patric 'TrueLight' Stout<BR>Retired OpenTTD Developer<BR><BR>-- <BR>Mark Kelly<BR>Manager - Information Systems<BR>McKinnon Secondary College<BR>McKinnon Rd McKinnon 3204, Victoria, Australia<BR>Direct line / Voicemail: 8520 9085<BR>School Phone +613 8520 9000 &lt;&lt; new number!<BR>School Fax&nbsp;&nbsp; +613 9578 9253<BR><BR>Webmaster - http://www.mckinnonsc.vic.edu.au<BR>IT Lecture notes: http://vceit.com<BR>Moderator: IPM Mailing List<BR><BR>Doctor - We must all face reality sooner or later.<BR>Dowd&nbsp;&nbsp; - I wrestled with reality for 35 years, doctor, and I'm happy to <BR>say I won out over it.&nbsp; ('Harvey', 1950)<BR><BR><BR>_______________________________________________<BR>http://www.edulists.com.au - FAQ, resources, subscribe, unsubscribe<BR>IPM Mailing List kindly supported by<BR>http://www.vcaa.vic.edu.au - Victorian Curriculum and Assessment Authority and<BR>http://www.vitta.org.au&nbsp; - VITTA Victorian Information Technology Teachers Association Inc<BR></DIV></BODY></HTML>