This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Forge.mil Update: Mission, Community, & New Things
It’s been altogether too long since I last updated readers on the state of Forge.mil, so I’ll take this opportunity to remedy that and share with you some of the things we’re most excited about, as well as reiterate the overall mission of the system. I think it’s important to make sure people new to the Forge.mil family of systems understand our motivation behind creating all of this.
With that, let’s refresh everyone’s mind about the mission and community Forge.mil was set up to serve:
Forge.mil Mission Mandate
If you look at www.forge.mil, you’ll see the basics of our mission at the top of the page:
‘Transforming The Way DoD Innovates IT’
There’s no doubt this is a lofty goal, but why start small? I also remind myself that IT is present in not just business systems, but also in defensive, offensive, and combat support systems. From the beginning, Forge.mil was never about remaking the DoD into an organization that used & developed nothing but Open Source software. In reality, that probably isn’t a completely practical solution, as many businesses have already found. In practice, there will most likely always be a mix of proprietary and Open Source software in use in DoD (and other enterprises).
However, Forge.mil’s goal has always been to take the methods and best practices of the Open Source world and apply those to projects in the DoD, a place not traditionally known for sharing. Since the core team includes several Open Source-savvy people, we also try to encourage developers, contractors, etc. to work in the Open Source world outside the firewall, if at all possible. As a matter of fact, we’ve rejected some potential projects on software.forge.mil because they were ‘forks’ of existing Open Source efforts that provided no value-add to either the DoD or the existing external community. (Conversely, there is at least one project with a DoD-specific fork which we did approve because it adds value to the DoD community that won’t be used in the civilian-side project.)
We also believe strongly in the work being done outside of the DoD firewall by groups like ‘Mil-OSS‘ (Military Open Source Software). Mil-OSS has a great vision of encouraging ‘innovation in the open’ in the defense technology space by gathering together like-minded individuals working on open source for military efforts. Because of their focus on moving things to the far end of the ‘openness’ continuum, some projects they are working with haven’t been good candidates for inclusion in Forge.mil – and that’s not a bad thing (for either party).
Projects such as Eurekastreams from Lockheed Martin are a great example of some of the very useful and cool work going on in defense being hosted outside of the DoD firewall. There is also excellent cross-pollination of people within Mil-OSS that work on projects both inside and outside of Forge.mil. In short, the two communities have a lot in common, and as you’ll see later, conversations between and among the people involved are starting to lead to some possible future efforts to help speed innovation within Forge.mil.
Forge.mil’s two main capabilities (software.forge.mil, and project.forge.mil) are about providing a space and a cultural shift within the DoD toward a more ‘open’ approach. Open is in quotes in the previous sentence because we view the system as somewhere in the middle of the ‘open and collaborative’ continuum – we aren’t open to any developer who wants to come in from outside the DoD; however, we provide anyone within the DoD community (including contractors) the capability to host a project ‘for free’ on software.forge.mil if they are willing to allow their work to be viewable by their colleagues. If they have operational needs that require they control the view and contribute access to their community, project.forge.mil is the space where they can do that.
Even in the private project.forge.mil system, we work with teams to get them to embrace a collaborative and Agile approach to their development. Sometimes we’re successful; other times, we fight against an entrenched culture just using our systems ‘because my boss told me to.’ However, we continue to focus our efforts on building and serving this community, because if we can’t get everyone to go the ‘completely open’ route, I’d rather we get them collaborating and re-using components internally, rather than the current defense status quo of completely siloed development.
Now that we know the ‘backstory’ of the Forge.mil effort, let’s talk about some of the newest things we’re working on, all of which are driven in one way or another by community input.
New Project.Forge.mil Pricing
First, we have new pricing options for our Project.Forge.mil ‘On Demand’ (shared infrastructure) offering:
- 100 users for $60K/year (previously the only option)
- 25 users for $25K/year
- 10 users for $15K/year
These prices include: up to 10 GB of storage, service desk support, basic project administrator on-boarding, platform maintenance and security. The two lower-cost options are a direct result of feedback we’ve received from smaller programs who want to take advantage of this hosted solution, but don’t have hundreds of developers.
Note that in an analysis of who benefits from using this for development, the government (and hence the taxpayer) would be the clear winners, not just in lower TCO (total cost of ownership) over the lifetime of the project, but more importantly, in transparency to the government task manager for the system being built. Today’s contracting world often relies on physical media (DVD, etc.) being delivered with the code at the end of a project, sometimes with no guarantee that the source even compiles or matches the system that was delivered. Even if contractors do offer access to their source code repositories, they are usually behind corporate firewalls that make it difficult for others in industry and government to collaborate on the systems being built. By encouraging contractors to use a common repository for projects that need to remain private (for a variety of reasons, not all of them necessarily security related), the government has the advantage of being able to easily see what’s been developed, and quickly bring in another vendor or contractor to help build capability in the system if necessary, thereby creating a cost-effective and competitive environment.
Clearly, this won’t necessarily please DoD contractors, but it would be a huge step in allowing the government more oversight of the systems for which they are contracting. Additionally, the funds being paid for project.forge.mil projects are the engine that allows software.forge.mil (and possible future ‘fast innovation’ systems) to be funded ‘for free’ to projects and contractors willing to work ‘in the open’ within DoD.
Next, we have something that the community team at Forge.mil is really excited about – the ‘Community Layer.’ This will be (when complete) a seamless layer on top of the existing CollabNet TeamForge infrastructure that allows us to ‘surface’ knowledge going on in various technology and mission areas across both software.forge.mil and project.forge.mil (if you have read permissions on specific ProjectForge projects). An example might be a mission area such as ‘C2’ (Command & Control), or ‘Chem/Bio.’ Today, we don’t have an easy way for projects working in the same (or related spaces) to collaborate on ideas, exchange information, or find subject matter experts with whom they can work. By allowing the community team (and later, users themselves) to collect these mission or technology areas and loosely bind them together, we are enhancing an already strong project-centric focus within Forge.mil to include more ‘social’ (an overloaded term we try to avoid) capabilities. Our goal is not to build the next military ‘Facebook’ (there are already several examples of that), but instead, to give users working to build software & systems some additional capabilities that allow them to draw on the wisdom of the collective crowd to build better software.
Additionally, capabilities such as per project/group blogs, calendars, and ‘voting’ capabilities are on the radar for implementation. We’re also working on a common search and tagging infrastructure to make information retrieval much easier across projects and Forge.mil capabilities. We’re basing this on the open source Drupal Commons framework from Acquia, and we’ll be involving the Forge.mil community as we go along to help us guide the vision.
At this point, I should point out this community layer is not (yet) ‘social coding,’ as defined by sites like github. There is work being considered (both from a technical and policy standpoint) to add these capabilities to the Forge.mil system, possibly as a separate ‘fast innovation’ system that allows low barrier to entry, but which could feed mature output into software.forge.mil or project.forge.mil (if it makes sense to further ‘productize’ an effort). This wasn’t in the original charter of the Forge.mil system, mainly because of the need to stick with just a few tools to pass certification and accreditation, however, contractor and other development teams with the requisite skills and maturity to take advantage of distributed version control and social coding without devolving into code siloing and code hiding are going to need a place to take advantage of the innovation advantages of this approach. Hopefully, replicating a transparent social coding solution such as that represented by github within Forge.mil would alleviate a lot of these issues. Since resources are tight all over, we’ll be evaluating if we can make a distributed version control system happen, and how we can involve those in our community who want to help.
We’re Not Done Yet…
All of these new capabilities come after a release where the team focused mainly on infrastructure and back-end fixes. The thing we’re most excited about is that unlike a lot of other DoD projects that deploy with one set of capabilities and then iterate slowly (if at all), we get the opportunity to continue to add new features and capabilities to the system not only by inviting other partners (such as the C3NCERT team at Hanscom AFB working on continuous build & integration), but also by engaging with our community members, who will help drive our vision (and in some cases, write the code).
The Forge.mil team isn’t satisfied with what we have today (and we know our user base isn’t). The team looks forward to building some cool new capabilities in the coming releases to help shift DoD development culture to a more ‘true open’ (where possible) model, or, at the very least, to make it more collaborative within the department. Stay tuned for further updates…