Procedures
Agreements and billing
Second Life residents are often — but not always — worried about their real life data. Many enjoy a degree of anonymity that is protected under the Linden Lab Terms of Service. Still, in real life business, this degree of anonymity may (or not) be desired.
When contacting us, we offer you two basic choices of dealing with us. You can work with us using contracts on emails or even notecards (signed in the in-world notary systems, or under Neufreistadt contractual law if you prefer) and pay us in Linden Dollars (L$). Payment, of course, can also be made through PayPal or bank transfers.
However, in some cases, you need more than that — you need a paper contract and a bill emitted by a real entity, which you can forward to your company’s accounting department. We are fully able to provide you with both, either in the US or in the European Union (Portugal).
There is no “one-size-fits-all” model for establishing a working relationship with our customers, so we are flexible to accommodate all your needs.
Development process
Beta Technologies follows the project model of most software development companies in the world. Once a customer contacts us, or is contacted by our sales force, we request specifications from them, as detailed as they can manage. Post-sales usually interactively discusses these details with the customer — often in-world — and gathers additional data: references, links to Web sites, images or similar media. At this stage, a preliminary rough budget can usually be determined and given to the customer.
The next step is to prepare the definitive budget. With enough specifications, usually one of our team members will now act as consultant for that particular project — depending on the type of the project, it will be mostly a programming or a building project, which requires a different person to work on the estimates. Team availability will be established, and the budget will have two different estimates — the total amount of time spent in development (which will determine the final price) and the estimated time of delivery, since teams usually work a percentage of their time on different projects.
The budget sent to the customer also proposes a standard contract form. In almost all cases, all content or developed scripting/programming will be released to the customer as open source, although the IP rights are retained by their original creators (our team members), which will release the code to the customer under a free license, without royalty payments or any sort of legal encumbrance, for an unlimited time, as long as the content/programming is used for the purposes described in the contract. Naturally enough, the customer is able to change the terms of the agreement to better reflect their needs.
Once the contract is signed (a simple email confirming its acceptance is usually enough), the work enters its design stage. The building teams might draw a SketchUp model for evaluation; in most cases, however, development proceeds directly, either on-site or elsewhere. The programming teams usually proceed to the design phase based on the specifications. Some teams might require more interaction with the customer at this stage; we have a collaborative Wiki, where both customers and team members can work on specifications or conceptual work together in this fashion.
Actual development is managed through an internal project management tool which allocates workloads to all the teams, plans the amount of time for development, and keeps track of spent time so far. Projects have several tasks which can be distributed to different teams; the tool also allows Gantt charts for overviewing the actual work being done. Every week the teams meet for a status report; afterwards, usually, either a project leader, or the post-sales will meet with the customer for their weekly reporting. We establish internal procedures for making sure that all steps of the development process are always overseen by several people — from project leaders to management — so that projects can flow smoothly and finish on the estimated date, while keeping the customer informed at each and every step of our development efforts.
All scripting and web-side programming is kept in a Content Versioning System and teams of builders and programmers are usually duplicated. Documentation is internally kept on Wikis as well. Textures for the builders are developed for each customer separately and kept in boxes for the builders working on a project. Thus, if one member becomes suddenly ill, the work can proceed without interruption with another team member. Similarly, due to the nature of Second Life and its restrictive permission system, it will be usually easy to recover work done by one programmer from the CVS and simply work from there.
This is our compromise on quality of the development process. We understand that many companies operating in the virtual world of Second Life are able to work faster — they are “just in time” developers — without any processes and relying only on their talent and abilities to work fast, redo their work as often as necessary, and charge low fees for their hourly work. We prefer an approach of “total quality” — work is planned, overseen, and organised, with tracking mechanisms at each step to validate the conformity to specifications. Our team is used to work under similar quality management procedures for many years — either in the building industry, the design industry, or the software development industry. The end result, for the customer, is a completed project exactly according to the original specifications — one that was developed from the very beginning to the end just once, and to meet those specifications,.
