 Okay, so while this is kind of gone, but I can start talking about my books today, this is already in the late, I'll be playing myself a little bit. I'm really talking about using 3BSD to promote open source development methods. This is largely not a technical talk, it's more about trying to create a cultural change within our company, trying to encourage more open internal software. We have about 2500 engineers who work for the US government in the area of national security space, and all of these engineers are in a wide range of fields, and interestingly though, a vast number of them with no correlation to what field they were trained in write software, which leads to some very interesting results, and has you can probably imagine. Because of that, we've evolved this very insular and cloned stuff for our culture, where developers will be writing code, they'll often be writing code with the things they learned back in 1965, 1970, sort of noting that our average engineer has less than a few years of experience, so we're fairly full of the company, and we're also widely distributed, so they're a key point. Now, in our current culture, we have two main camps. There's a set of classic software engineers, and these really are software engineers. They build big, huge, important things. They build flight control software, they build onboard processing software, and all that sort of thing for satellites, launch vehicles, you name it. They generally get the job done, or rather they help contractors in the Air Force get the job done, but the process is huge, it's expensive, and if you've ever actually tried to do anything in it, it's quite painful. Any change, even fixing a typo in a comment, requires filling out a paperwork. It's incredibly insane. Another camp for people, though, that's the people that write engineering support software. These are the people I was talking about a little bit ago, and they are, as I said, not trained in this. They're writing software to solve today's problem, whatever the heck that is, and unfortunately, that software continues to live on, it grows, it's a giant snowball becoming an avalanche, and there are cases of software that has hundreds of thousands of lines of code that people are using that's suddenly become a product in some cases, we're shipping it out to people, and yet the processes they're using are very old. Maybe writing is what they're writing in APL, programming language, where if someone else can read your code you're doing it wrong, or as I say here, inside, they put in this provision control as the ones who have a file server somewhere, and then they have a whiteboard where they log files, so they don't see the things we all take for granted. In many cases they don't know how they exist, they only know about the previous culture, and they're like, I want nothing to do with that, and rightly so. So the problem is obviously, some of the bigger ones are, they've got their own code, they're hiding it from other people, they're kind of afraid to let it out for many reasons, and for instance, they think it's ugly, they're probably right, they think it's ugly, so that's a problem. There are also cases where they're afraid people are going to misuse it, that's a very viable, very common belief that somebody else will use it, but these are wrong, and the developer will be blamed. Supposedly it's even happened in a few cases before a little weird declaration. There's also our CAD, we have some Fortran code that's widely used, uses features that deprecated Fortran 77. They've had 30 years, no progress has been made, and many obsolete practices. As I say, no revision control, people don't know when things broke, just they did, they may have met with somebody checking a bug, or maybe because two people did something that caused an interface to change, and didn't adapt. Features often get lost, we've talked to people who are customers of one of the pieces of software externally, and one of their comments to us was that someone just off the cuff was, it'd be really nice to burn the revision control, because sometimes features go in as we ask for them, and then in the next revision they disappear. Probably because somebody didn't manage the locks, the guy who was building it put the feature in, and copied back the server, boom, it's gone. Releases are repeatable. And they waste a phenomenal amount of time and effort to manually doing these locks, manually merging their changes, they didn't really know about the diff. It's kind of crazy. So if we're promoting a project that I'm working on, called Aerosource, it's a promoting open source methods, and we're proposing them as an alternative, and using creepiest eaves, for instance, as an example of what you can achieve with these methods, that you really can build big, huge production systems that are quite capable of doing useful and interesting things without this classic software engineering methodology, and with methods that actually we hope will actually be in less effort than their current and really lack of anything. And it's worth noting that one of the things we push a lot is that open source methods are necessarily low friction in some sense, because developers largely have other things going on, Kirk said at the previous EuroBSD con, that one of the things you have to deal with is that in an open source project is that your project is the last priority of your developers. They've got vacations to go on, they've got jobs, they've got family, all that. Similar down the line comes your project, so you have to be reasonably good at keeping the friction down. We're also hoping that if we do not have people start making their code accessible within the company instead of hiding it from each other, maybe the 6 or 8 or 10 implementations of some pieces of code will converge into one good one instead of 6 or 8 or 10 bad ones. And the fact that we're using open source tools as well helps reduce the objections to cost. There's still the objections of, I don't have time to learn this, et cetera, et cetera, but at least this stuff doesn't cost them anything. And the way we're currently funding it, we have internal funding, so they don't have to pay. We're sort of spinning the concept as enterprise source software. It's exactly like corporate open source software, except it's inside only. There's no, by putting your stuff in our repositories, there's no implication that this is going outside it. In fact, that would be a violation of company practice. To release software outside it has to go through a release process. So it's actually fairly hard for us to convince people that really this will work, but that's the, where we have it's working. So it is worth noting that it's not really using open source software within the enterprise, it's in fact this process of doing open source development just that we draw a line around it and it's based inside the company. But of course enterprise source can become open source software and we hope that in some cases that will happen. That we really will start to produce more open source software in cases where we have pieces of software that are not restricted for apparent reasons of national security or whatever. And of course another key point is that open source software can come in obtainable. And if say it's an abandoned project or we've had one case of a government run project so it's public domain software that doesn't really have an active retainer, we can bring it inside, maybe hopefully we will at some point bring that back out. But things can come in that way as well. So the era search project. Our goal was to promote this enterprise source software to provide developers with good tools and sort of modernize the process. But now we're not trying to bring them up to today. We're going for, you know, we could go with getting them up to the mid-90s, you know, CBS, Wells Subversion and that sort of thing. Distributed version of the tool is probably way beyond them and that sort of thing. So, you know, we're just trying to sort of raise the bar and get people up to the point of sort of the default in open source software in terms of tools and maybe get them a little better than that in practice. You know, if you look at that source point where people openly know how to use the tools, it's pretty obvious they're not really using their testing step. So, to do this, we wanted to implement a source-forge-like thing. So, you know, we had to have version control. We had to have bug tracking. We needed somewhere for people to maintain a website so people could find their stuff and, you know, find their documentation and all that. Ideally, we needed to be well-integrated and, of course, since we were talking about enterprise source software, it had to be internal access only. Basically, you know, our own source work. You know, also, because of our funding model and because of the package, you know, eventually our funding will go away and we'll have to sort of steal money from other places or start taxing the users and because all the people in our group massively over-subscribed and very inappropriate, then we needed to it needed to be easy to use, operate, maintain, modify, what not, because, you know, we've got to you know, we'll do this fairly quickly. Now, we looked at a number of options. Source-forge, the main software was write-out. It was too expensive, you know, and we certainly weren't going to stand up the ancient pieces junk that they did release five years ago. We actually had done g-forge in the past. We had a g-forge installed, even on the same machine. It was far too much work to do upgrades. And we actually had track, sort of running it in a multi-project mode in about half a day, which was about, well, where as the last g-forge upgrade took a week, you know, that should give you a tip off there as to what's going on. Another one we should have looked at but didn't know about at the time was our retrospective. It's a re-implementation of track in Ruby on Rails. Track is in fact in PHP. By default, sorry, yes, it's not modified much myself. Or there's a person, he sort of you know, throw it all together. You know, we already do a lot of VEO, we already had CBS's version stuff, we had a bugzilla server, but there are ways you could tie them together a bit more, but we sort of decided you know, we're not going to do that. Well, there's a difference between in Rusty, between track and the next one. Is that a retrospective? The reason we should have considered a retrospective are the pros of the literature in summary. Track, for instance, has as a wiki, the biggest problem that we've run into is that it has a wiki that if two people were editing, the second person loses their edits when they get submit. There's no dip, there's no nothing, just boom. Retrospective is a result of some people's frustration to be built up with that not getting fixed and with some other patches, such as a patch to make the wiki store itself in the subversion not get fixed. So it's a re-illumination, it's a little less mature in some other areas. But we might have gone with it, had we found it at the time. So I'm not even sure if it's not areas we're necessarily worried about but I don't know that we would have. It's hard to say and problems we perceive with track are perhaps the biggest culture. So there's the stack, so track, subversion, the usual lamp, or in this case, bat. So there's a screenshot you've probably seen the easiest URL I give you is probably varnishcash.org it's not a track project. Actually, one thing we're noting here is this little sidebar on the left shows all the projects that we currently have and that's a little way we add it. Now, so promoting notice stuff. How are we doing this? We've been doing internal and external presentations, talks about open source, talks about open source methods and talks about enterprise source, both inside and outside. Inside, we're directly promoting outside, we're doing development sometimes we'll have people from our company show up in these outside things and also I think it just gives us some credibility and other people are willing to come and listen in that regard. Now, we've also been giving demonstrations of all the tools inside the company and in some cases, we've managed to list portions of our management who have told their projects that if you'd like to keep getting funded, you need to adopt these tools. One of the things to do is we use the previous project as an example to show what can be achieved and also provide examples of working practices because there has been research on how 3BSD works. We've got a number of great presentations and it also gives examples of how you can manage your project and have different indications. One example, next to Trin, we use Robert's how the 3BSD project works and go through and give the talk, it usually takes an hour and a half, two hours or one hour or up. In the case I'm showing here the 20 minute version where he puts multiple slides together. So what are our experiences here with getting people to use the software? Existing users of CVS or Subversion are like, great, you're maintaining this, it's backed up. You guys, what you're doing around the Unix system, great move over right away. A number of people do that. A lot of people have been moving their Subversion repositories over and that sort of thing. Also, new projects seem to be interested we're getting a number of startups and that's been going well. People clearly are realizing in parts of the company that this whole group control makes a good idea and maybe they should use it and either of these tools they're going to come and use ours. So that's been good. We've been using it internally using maybe the tools since we've already got this infrastructure here for like the first game. We've been using it for system management tracking our configuration on various machines using the ticketing system to track issues using it on my cluster to track what nodes are broken and that sort of thing. However, we have seen some strong resistance. So there's some objections. It's my code I can decide whether people can see it or not but actually not really standard contracts in the US is a work for hire contract and so really the company owns it and it's up to them to decide how it gets used. It's embarrassingly bad that's sometimes true and I can sort of sympathize with that but if you just hide it, it will never get any better or it's very unlikely to that you have no training and no experience in how to develop modern software. We've actually had this thing that rewriting basic algorithms is a rate of passage where you should write something to parse two parent elements that's for real satellite organs. It's always good to re-implement early 60s technology, early 50s technology or perhaps it's a pointless waste of time. In some cases, it might actually be true if you're talking about some of the old little algorithms and that sort of thing where we're building on top of those but there's no way this prevents that. We're talking about generally upright reasonable people who are not going to go off and cheat when they're given this assignment. It might be good if they founded themselves and that would be a sign that they succeeded but if they need to do this and they're doing it for their education their adults, they have security policies and whatnot so probably you can trust and implement it themselves. Another objection is only I can maintain this code. In some cases that's probably true but that's more because it's a big pile of spaghetti or it's hand rolled FGF line in get C and re-hoc for everybody and but your coworkers generally in this case aren't all that aren't stupid our goal is I didn't really talk about it back in the beginning one of the things is that one guy I know is giving a talk on our company and likes to say we've got to be the smartest people in the room when we walk in with a contractor in the Air Force because we're the ones who are tasked and on track so we do a lot of different types of people so it may be true that the code only has one maintainer now but hopefully we can fix that I think a bus pack or one is generally bad only I can use it correctly as it comes back to this case of people saying if I let people have the code they might fill out and compile it and run it and then they might misinterpret the results and I could yell at it another one is people might submit changes and I'd have to work on it I'd have to improve it this happens I'm continuously clever as different people express that and I'm like isn't that a great problem to have surely we can find funding to ensure that you can keep up with this wouldn't it be great if there were 20 people contributing to your project to make it better apparently not not for some people so some projects in Aerosource Aerosource itself isn't back in Aerosource it's the main project what sort of redirects to a track instance and we keep all of our management scripts and everything in there working the title forms in so when you request an account it goes and creates a ticket for it not right now it just sends an email and we do it you know Aerosource which is our internal ports collection I'll talk a bit more about that later Volant is an internal system for taking telemetry streams from launch vehicles as they pass over different receiving stations on their way out to orbit they'll take off from the Cape flyover of Sunshine Island another island out in the Indian Ocean and they pass between these tracking stations they're received by multiple antennas there's jitter strange designed to sit in where things are time stamped after they receive time or not on the vehicle but after they go through a long complicated network we're very able to look at it and so you've got to stitch all of this back together there may be compression and expansion of things things are lost through the plasma flare so this is tools to do that fellowship is our cluster we keep a lot of things in there Firewatch is a center web project we build tools with different little modes out in the in Southern California to just hack fires and provide alerts when there's a possible fire condition SOAP is probably our biggest success thus far it's a project that we actually ship out as a product it's a tool for viewing satellite orbits doing analysis on them doing parameter studies and other things and we're just getting started there so, era sort of maintenance one of the big things is we eat our own nod to it because I said all of our stuff is in there we do all these all management there and the front page of our project and our main presence is in fact just another instance of a project we've made pretty much basic pre-PSD mostly standard ports plus some special local use ports we're modifying panel because our corporate LDF scheme is not right things like that we also do backups so we can sort it to that sort of thing so arrow reports it's aerospace specific ports we're using a a set of tricks that Scott Ketzel posted when we create an arrow directory inside it's essentially a miniature of course 3 with the normal 2 level hierarchy and then we've got a set of tools we've got a confusing we named for example APT which is the aerospace ports tool it wraps a port snap and subversion so it keeps it up to date copy uses a nice feature column and add it for me to allow you to create the index only having to run the M.A. described in the subtree instead of doing the whole 16,000 ports it works very well it's also an incubator for external ports the replacement root specific ports started there because I needed one and I knew the other one was going to die eventually because I had a lot of people kill it so that was the start here's the tool I'm afraid we'll have to stop your jokes okay I'm on the conclusion page so we are attracting customers it's doing pretty well open source methods are attracting developers and we're getting traction there in the future we want to do more storey sort of things improve automation etc etc there we are thank you