Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Aug 10, 2010 — Enterprise Agile Planning expert Update: Mission, Community, & New Things

Enterprise Agile Planning


It’s been altogether too long since I last updated readers on the state of, 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 family of systems understand our motivation behind creating all of this.

With that, let’s refresh everyone’s mind about the mission and community was set up to serve: Mission Mandate

If you look at, 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, 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,’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 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 – 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 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’s two main capabilities (, and 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 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, is the space where they can do that.

Even in the private 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 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 Pricing

First, we have new pricing options for our ‘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 projects are the engine that allows (and possible future ‘fast innovation’ systems) to be funded ‘for free’ to projects and contractors willing to work ‘in the open’ within DoD.


New Features

Next, we have something that the community team at 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 and (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 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 capabilities. We’re basing this on the open source Drupal Commons framework from Acquia, and we’ll be involving the 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 system, possibly as a separate ‘fast innovation’ system that allows low barrier to entry, but which could feed mature output into or (if it makes sense to further ‘productize’ an effort). This wasn’t in the original charter of the 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 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 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…


More from the Blog

View more
Apr 08, 2021

Making IT services more agile

Enterprise Agile Planning
The agile revolution completely transformed how we create digital prod ...
Read More
Feb 14, 2021

Reflecting on the 20th anniversary of the Agile Manifesto

Enterprise Agile Planning
Over the past 20 years, it’s been amazing to watch an idea from ...
Read More
Feb 08, 2021

How does agile apply to an entire organization?

Enterprise Agile Planning
Before we dive into the main subject of this blog post, it is importan ...
Read More
Feb 03, 2021

It took a pandemic to realize why digital transformation actually matters

Enterprise Agile Planning
Before anyone had ever heard of COVID-19, businesses across the globe ...
Read More
Contact Us