 Ches, Chris. So, I'm afraid it might not be quite as exciting as what Adam presented before, where exciting things are going to PHP 5.4, but it's quite an important topic. So, in de ferro is a source code and project management application. Now, that's not particularly useful with information. When I say project management, it's more from a point of view of being able to track things like issues, documentation and other bits and pieces relating to a development project, rather than the whole commercial point of view of project management, which is draw to schedules and lay up the issues and track them all and that sort of stuff. It combines the functionality of a typical SCM viewer, so things like, for example, our viewVC, along with other tools like a basic wiki, issue tracker, into a single application, which makes it really easy for small and medium-sized projects, in particular, open source projects to use. And it's fully open source under the GPI license, which is wha I'm hearing and talk about it. So, wha am I hearing and talking about in de ferro to begin with? Well, I'm not an issue developer of a project. Amidimus uses in de ferro for all of our internal project tracking, as well as our public tracking. And that really started the process about a year ago. We were originally started as a single person company myself, using a CVS machine in a back dark room, which we never spoke about. And we're using it a little bit more flexible for multiple contributions to use, staff, and so forth. So, we came out with a few different requirements. And what we realised is we needed something that provided the ability to view the source code via the web-based interface. I mean, you don't always want to download the entire repository to go and find one particular file that you're interested in. Issue tracking was a major one. If you've ever tried using a mailing list for all your bug reports and feature requests, things tend to get dropped and forgotten by your developers pretty quickly. So that was two main points for us. The other ones is we needed the ability of public and private projects. Being open source focused, I'm sure many of you guys have released most of your code openly and publicly, but now and then there's something that's either too embarrassing to release publicly or you have a specific customer fork which has to be kept internal and hidden. We also wanted different access levels. Now, we were operating on a module where three developers working full-time, various open source contributors wanting to jump in and look at things, and also some customers for particular projects wanting to be a log-on and maybe check some source out which I didn't necessarily want public. So we needed a system that was very flexible without being for traditional one box for internal, one box for customers type of model. We also wanted support for multiple versioning systems. Now, as I mentioned before and please never repeat this outside this room, we used CVS. We later upgraded to SVN, oh dear, been recorded apparently. We later upgraded to SVN with an obvious migration step and we're looking in the future and using things like Git. And we also needed a low barrier of entry for users. Now, our staff ranged from relatively skilled gurus down to UI developers, graphics people, and contractors coming in to do a little bit of work. So we needed the ability to scale for all skill levels and find a system that worked in-between. Why am I taking a button to fair again? I think it's a fantastic application and the point of view, I've committed a couple patches to it but the majority of it's written by some other people or together. I'm talking about it because I think it's a really, really good tool. I also think that everyone in this room should be using something like Interferu. I imagine a lot of you are and I'll cover some of the other options shortly, but if you're not, please pay attention because this will make people's lives so much easier. Saving Source, we're going to promote another source project and it's written in PHP, so I guess the next question is why not one of the million different options? Well, from my research and experience it came down to two different categories of alternative options. You had a traditional Unix style approach of choosing one tool for one task. If you could choose, say, a bugzilla, bug tracker, you could choose something like a Benton which is done by mySQL, slash sun, slash oracle, slash whatever they are now. Media wiki for your wiki information, so forth. Now, that's quite a good model for the source-based size of Unix or the red hat bug tracker, things like that. Things that are really, really large, having separate tools does make a lot of sense because you get more control, more functionality and so forth. However, in our case, our projects ranged from our largest which was our budding system and we're only talking maybe 50,000 lines down to five line script files for an RGSE we wanted to keep track of. So that wasn't really a suitable option. We don't want to spawn up another copy of the applications every single time so we'll look at some of the other ones around. A lot of you are probably familiar with GitHub or Gatorious. GitHub being a proprietary network, I believe, and Gatorious is based on an open source code base. There's also Google Code which seems to be increasingly popular lately. It's a side note that Indefera was originally developed as an alternative to Google Code. Manuka's main developer was trying to export his project one day and found he couldn't do so very easily and you'll notice there on the screenshot I'll show you, it's quite similar to Gatorious and functionality. The cool thing is, it's going a lot further than Google Code has and you can change it yourself and so forth. And it's also Launchpad and many many others Sourceforge and so forth. I think Indefera fits in quite nicely in this ecosystem, it sort of fills in niche a lot of us don't really do. They tend to focus on mainly the large scale deployments or hosted deployments. But I mean, have a play around and see what one suits you guys best. The one main reason we looked at Indefera was options like Gatorious and GitHub with support for model SEMs. Now, for the base features of Indefera, you actually have support for not only SVN, but Git, Mercurial and of the next upcoming release there's also support for monotone. So, I'm not sure what clearly it is to see but it's a pretty straightforward interface so it's kind of cloned a bit of the Google Code look. This screenshot there is just of the source code viewer who can browse your projects so forth and you can see what we're watching. One of the neat features that came with is a changelog page. You can actually just jump on there and see who's been working on projects lately and track through and see all the latest commits being made. Again, it's an SEM viewer. It's not that exciting. These are trackers where more true stuff happens. Now, it looks pretty basic. You've got the ability to post issues, numbers, flag numbers, favourites, and tag them and so forth. Now, at AmbitDMS we had a problem of developing a lot of web applications and developers have got to do their thing, make a bunch of database changes and need to track them. So, we were using deferrer to collect all the SQL changes that were being made and before issues were closed we'd grab them, stick them on a file and commit into SVN. We also found out a fantastic way for actually developing without necessarily being in the same location. We could set up or design the user interface of the application. So, we had a huge break checking scanner and uploading it straight into deferrer. Now, even though we're in the same office, this offered the great ability of having open source contributors and developers see what else was going on and not being locked out of that whole development process, which is easier to do especially when you can just talk to the developer sitting next to you rather than posting to the mailing list. So, we tried to structure all our processes around in deferrer tracker. The other great thing about it is the tagging is very, very flexible. Now, a lot of problems I've had in the past with some more enterprise-focused applications, for example, a event developed by my SQL is they're very good for a very rigid business process where you set up your existing tags and therefore you deal with. Within deferrer you can go and set up your existing tags to begin with, like your version milestones, your priority levels, so forth. But you can also then go and set them on the fly when you post issues and when you're working on a small project it tends to happen quite a lot. You can then say a new templating engine so you want to go and tag it. And you don't necessarily want to have to wait for the admin who's running on a different clock cycle to go and actually add it for you. So it made it really, really easy to work on small projects with multiple staff. The other great thing about it is we needed to play thick documentation publicly for applications. And the format wasn't like a PDF file upload. And in deferrer actually had a wiki functionality built into it. I wouldn't admit up front it's not the greatest wiki. It's not completely fresh in terms of features. But it does the job. It allows you to post documentation. We use it mostly for installation guides and so forth. And it does the trick. And it was a fair bit of work, I believe, going on in that space. And deferrer also has some very nifty features. Now, one of the ones we loved is the password and key synchronisation. Typical problem I've had in the passwords, some of the projects I've worked on is your environment might be a FVN or CVS box with access to the machine. So you have to talk to the admin to get yourself a password created before you can commit to the project. And then someone changes your password somewhere else but doesn't change on that machine. So on and so forth. In deferrer, I made it really easy. Basically, once you set up the user, it will write your user's password or your SSH key into the files of the machine. So HD access or via SSH authorized keys. Basically, it means as soon as you add a user and permit them access to the project, back-end SCM as well. Very, very handy. Of course, we should all be using centralised authentication, but that's easy and said and done sometimes. And that's what brings me on to the security considerations point of view in relation to in deferrer. In image before, obviously you've got public-private projects and you can delegate access between those and different levels. And I'll just show you a little example. That's basically the flow of moving someone from being a purely public user all the way through to being a developer. Essentially, they can create a user account. They get read-only access to your repo, which is public, and you can upgrade them to commit. You can say they can read and write this project but not another one. It's all very, very integrated, rather than doing the approach of having users per project or users per instance. Made it very easy to revoke user access as shown in the fourth password key features. A user leaves a project or you have to get rid of a staff member or something like that. Revoke their access, pulls them out of the SCM as well. The other great thing about the deferrer is the ability to limit access to particular functions on the application. Sorry, wrong slide. Often, you don't need all the different bits of pieces. For example, we very rarely use the download function. We can upload files for later download because we have repository service set up for that. So you can just turn the feature off. Or you can decide that we want the user community to be able to contribute to the wiki. Sweathass? Allow them to do so. We've had people trying to abuse us and put malicious instructions into the wiki. Maybe we should lock it down to project members only. You've got a lot of control over what level of access and right abilities you want to grant to the users. I've listed a mention as well as you can go from a private project to a public project if you're enough. So if you're still working on something to embarrass the reviewer straight away, you can certainly do it private and then release it later on. Next thing I want to talk about is project planning within deferrer now. There is basically how we did project planning within deferrer using a marisi traditionally printed off materials and circled with pen and labelled from there. I would admit that the project planning within deferrer is a little limited. I have for a moment its capabilities is pretty much limited to displaying completion levels for onto the target. One of the good things that you can do is you can select a tag and fill out one tag that will show only relevant issues and the completion level that you've done on that. It's very rudimentary. Something like, we'll complete your fresh list in terms of functionality far, far more advanced. On the other hand, this is about to be a young project and commits are always welcome. And for us, that's the trick. We usually track that project process via a different means. Well, but central of the communication, as I said before it does do via whole key and password to a file feature. As of a recent version as in trunk, not yet in a stable release it does now support LDEP for back-end authentication and you can also plug in your own authentication modules in as well. Just for those of you trying to fit into a bit more of a structured environment. The question was has anyone done OpenID? I don't know the answer to that one. I suspect not because this feature is quite new but you can certainly write one because it does support different back-ends now. Underneath, we're using a framework called PLUF which is developed by the same developers as in the Fero. If you know, whenever you develop PHP application the first thing you should do is invent your own framework. It's actually not too bad. It's a reasonably structured MBC style application framework. There's authentication, templating data structures in the background. There's a homepage up there as well if you whatever reason want to take a look at it. They are in the process of doing a whole bunch of rework with that framework. It is talking about getting thrown out and replacing something else or get merged into a bigger framework that they're currently building. I'm actually reasonably happy with the framework. I can't really complain too much. It's a pretty lightweight which is also really good. This whole application is really, really light. If you're downloading and checking it out right now I'm really sorry because installation is a little bit tricky. Essentially it's been written by developers, for developers and that tends to mean installation guides and manuals and easy one, two, three methods tend to come last. Essentially you have to install the framework as a separate package and then install the application and do a bit of configuration between them. It's not too hard, but it's a little bit more than most people like and I'm hoping to make some time as you sit down and make a nice easy installer for that. Apart from that, it's pretty easy to install basic requirements and no matter what sort of data base family you might be you should hopefully find an option which isn't data too terrible for you. That slide is slightly incorrect. We now support Git, Mercurial, Subversion or Monotone. It's under active development. First started in 2008. We started using it at AMDMS in early 2010. Stable as of release 1.0. In fact we're still using release 1.0 and we've had almost no bugs. We're pretty happy with it. As I mentioned, Monotone SCM is coming in the 1.1 release and there's a whole bunch of talk going on about the 2.0 release at the moment on the mailing list. We're looking at moving to MongoDB and there's a few bits of talk about what's going to be in there. But it's still quite up in the air at the moment. There's no data consensus I don't believe at this stage. So that's the majority of my talk. There's a few links to check out. The first one is check out their homepage. Indifero do a whole bunch of hosted versions to try and make some money from the service as well. But there's also a whole bunch of information regarding application and links to the open source parts. If you just care about the source code, next link down. There's a mailing list. There's reasonably active. There's quite a few uses on there and developers tend to respond quite quickly to anything that's going on as well. Otherwise, feel free to come talk to me about Indifero. I don't put along a slide, but if you check out www.AmbaDMS.com. You can see how we use it at AmbaDMS. It's got all the open source stuff up on there. Otherwise, check out my website if you want to grab the links and feel free to come talk to me. Or you can ask a question right now. OK, we'll start with you. I've actually been tweeting about this while you've been talking. Why didn't you use a track? I looked at track in the past. I just didn't like it from a usability point of view, but that's just more personal preference than anything else. Like I say, when it's an open source project, you've pretty much got another five options to anything. We just found this one a little nicer. Anyone else? What sort of options have we got when you're one of the fat controllers or something when you're head boss and you want to get a dashboard sort of overview? You can view all the issues which have been assigned to yourself and you can view all the projects which you have access to. In terms of an overlord control panel, there isn't one per se. There's a little limited in that respect. Any further questions? OK, so if there are no further questions, everybody please thank Jethro for his talk.