JohnMark.org Headquarters

There has been a ton of information (both positive and negative) written on the concept & theory of the ‘Digital Water Cooler.’ You can check Google for the proof of that. What I think is interesting from a business perspective is how some companies are capitalizing on the positive aspects of this phenomenon through effective use of social media, while others subscribe doggedly to Taylorist management principles, which suggest that all such activity must be frivolous because it can’t be measured.

Although I’m involved in community management, I still consider myself an engineer (or, at least I haven’t lost my engineering mindset completely). I like data and measurements as much as the next linear thinker. However, I’ve experienced first-hand how utilizing social media in proper amounts has benefited cycle times, increased worker productivity, and generally moved projects along in a more efficient fashion. The problem is, it’s usually difficult to measure the actual effect using these technologies has had on the work. That may still be the case, but recently, Matthew Hodgson wrote an excellent article on ‘The ROI of being social at work.’

In this post, he cites research from MIT (full text available in Harvard Business Review) that showed “40% of creative teams’ productivity is directly explained by the amount of communication they have with others to discover, gather, and internalise information. In other MIT studies, research shows that employees with the most extensive digital networks are 7% more productive than their colleagues.” The study showed some interesting traits and differences between what are termed ‘creative teams’ (marketing, PR, etc.) and ‘implementation teams’ (engineering, IT). It isn’t too surprising that teams charged primarily with implementation focus less on social interaction than do their creative team counterparts. However, from personal experience, I’ve found there are people who have to live between these two realms. Sometimes they are called project managers, technical marketing, pre-sales, or services. Now that I live in this space in my current role, I can see much more clearly how judicious use of ‘Digital Water Cooler/Hallway’ technologies like Twitter, Facebook, LinkedIn, and FriendFeed help provide a competitive advantage (if used properly) in the enterprise.

The potential for abuse of these tools is always there – I remember a time not too long ago in my career when I would factor in whether a company had open email, web, and Usenet feeds (wow, I’m showing my age there) before determining whether to take a job. A lot of these things were banned or severely limited not long ago, but now, access to these kinds of tools is taken for granted, and I believe most progressive companies realize you have to put some guidelines in place for use of social media, but at the end of the day, you have to trust that you’ve hired professionals who will use the tools wisely.

What’s next for social media? Who knows, but I think it is critical that collaboration tool providers (such as CollabNet) determine how to integrate the data provided by such tools into their own platforms. The company that can figure out the most comprehensive way to coalesce all of this information into an easily synthesizeable format is going to have a large competitive advantage in providing enterprise users who fall into the middle ground between ‘creative’ and ‘implementation’ teams with access to tools that increase their productivity and ROI.

To begin with, of course, CollabNet employs several primary committers specifically to work on Subversion. In addition, from asking around about this in the past, I’ve learned that there are one or two others who are explicitly employed to work on Subversion as at least a part of their formal job description. But most of the others do what they do because they themselves, at least, recognize that it’s the most efficient way to get good version control for their company and profession. These people aren’t just creating Subversion, they’re not disinterested (or fanatical) hackers: they’re giving back. They’re contributing to the commons.

Why does my survey differ so markedly from Matt’s? Hard to say, but I have a couple theories:

• Maybe the give-back ratio among enterprises doesn’t really need to be any higher than among the general population. It’s pretty well accepted that the proportion of users of any given open-source project who actually contribute code is quite small; maybe the same is true of corporate consumers. In which case, both Matt and I have skewed our results by our survey sample. 
• Maybe the CTOs and CIOs Matt surveyed just don’t know what’s actually going on down in the trenches of their companies. Much of open-source give-back is at the individual contributor level, anyway. Very few corporations I know of have policies or reporting structures around such things. I’m a CTO, for instance, and although I happen to know a lot about our Subversion contributions, I know vastly less about our contributions to the other 200 or so open-source projects on which we depend. 
• Or, who knows: maybe this is just one more way in which the Subversion community is head-and-shoulders above any other open-source community. Wouldn’t surprise me in the least! 

  

This all has important implications for the inner-source community as well. You can have a healthy inner-source project with very small contribution rates from the rest of the company. You shouldn’t take that to mean the project is unsuccessful! Success is primarily measured by reuse. Contribution is a way to get there, not a measure of having arrived.

I’m sitting in beautiful Charleston, SC, where I just finished attending the Forge.mil release 1 review/release 2 planning meeting. There were some great discussions that occurred, since we had almost the entire deployment/development team here in the room (we ‘eat our own dog food’ by using the system to collaborate across geographies and DoD components normally, but some ‘meatspace’ time is always good too).

First off, I’d like to correct some erroneous information that has gotten out in recent press articles/blogs about Forge.mil. The correct URL for the site will be (eventually) http://www.forge.mil, NOT https://www.forgemil.com. The latter is our test site, which has since been locked down from public access to prevent confusion that came out in when Slashdot picked up Matt Asay’s article on this. The former currently requires a DoD CAC card, or ECA certificate to access the site (available to DoD/miltary personnel, and government contractors). Before we go into our ‘official’ launch at the end of March/beginning of April, we’ll open up www.forge.mil so it is easier for interested parties to see what the capabilities of the system are.

Second, let’s clear up a misconception going around that the first capability we are delivering (Software.Forge.mil) is ‘not Open Source’, because it will sit behind a PKI-layer and not be available to the general Open Source population. Yes, strictly speaking, it isn’t ‘Open Source’ in the traditional sense, but the reality is the DoD is attempting to utilize development models and methodologies from the Open Source world to help develop and deliver software more rapidly and in a collaborative fashion. The current plan is to limit this for internal DoD and contractor community use, but that could be re-evaluated at some point if it makes sense from the community standpoint.

Third, the software infrastructure used to deliver the capability is not SourceForge.net, but is actually the CollabNet SourceForge Enterprise product.

With those things out of the way, let’s talk about the meeting. Basically, we got the team together partly to go over the accomplishments of release 1 (ok, and to celebrate this first release with the entire group, since we don’t regularly see each other in person), and to work on plans for release 2 (the ‘official’ launch). The three elements we are targeting for release 2 are:

1. Build Community
2. Mature System Capability
3. Build Partnerships

The Forge.mil system is a ‘platform’ effort, which will eventually deliver the following capabilities to the DoD community:

1. Software.Forge.mil
2. Project.Forge.mil
3. Standards.Forge.mil
4. Certification.Forge.mil
5. Test.Forge.mil

Release 1 delivered the Limited Operational Availability (Beta) phase of Software.Forge.mil. Release 2 will be the official launch of Software.Forge.mil for internal DoD and contractor partner access.

We started yesterday with an overview of where we are to date, including some great stories I was able to share on community. Specifically, I created a ‘Utility Library’ project to host requests we were seeing for full blown projects on the site that didn’t warrant that much overhead – usually, these are smaller ‘code snippets’, scripts, or self-contained libraries. After I created the project, I was able to recruit two users (the first two to contribute code) to become the project admins. I introduced them to each other (one from the Army, one from the Pentagon), and away they went. I removed myself from the admin list for that particular project, and they are now running it themselves, and onboarding new users and code for the project. It seems like such a little thing to those of us from an Open Source background, but this simple act is a HUGE deal for a government space that has traditionally not seen a lot of this kind of sharing.

We are also seeing a lot of excitement so far in this limited launch, with projects/programs literally pinging us every day to inquire about the system. We’ve put in a very lightweight governance/adjudication process for new projects on the site – the only thing it is there for is to make sure the project meets the terms and conditions (fully public/open within the DoD community), and that there aren’t duplicate efforts going on. So far, we’ve been able to shepherd several groups together that either didn’t know about each other, or hadn’t been able to collaborate before.

Again, I know this sounds very mundane for those of us used to the way Open Source projects and methodologies work, but this is literally starting to ‘change the world’ for these folks in and around the DoD. I know there will be future challenges along the way, but this effort is very visible (even at the Joint Chiefs of Staff level), and the excitement and momentum is palpable!

Finally, I should take some time to mention the implementation team. It is made up for DISA personal, CollabNet consultants, and members of the Navy SPAWAR command. This meeting (the second of two face-to-face planning/review sessions) went very, very smoothly, with the members of the government community really starting to see the power of Agile development and collaboration. We started the build out of this project using Agile, and delivered this initial early-access capability in 90 days, which is practically unheard of in the DoD (or any government entity for that matter). This is a testament to a group of folks who are willing to blend the unique expertise and perspectives of traditional government development and procurement with Agile processes. I won’t lie and say there haven’t been challenges along the way, but, so far, each has been met with determination, and a team spirit that I’ve rarely seen in my career (in fact, I’ve only seen it at two previous career stops).

I’ll continue to keep folks updated via this blog, as I think this is going to be a very exciting project, even if we just build the capability for internal DoD use only. The methodology and capability we are bringing to the table have a chance to fundamentally shift how software development is done in the department, and this can be a model for other government groups as well. Now I’m going to get on a plane back to California and get going on release 2…

I’m sure a lot has been written about the subject of trust within communities.  As I’ve been working through the community launch plan for forge.mil (more updates on that in a future post), I’ve been thinking quite a bit on this, and two things spring immediately to mind: ‘default to public’ and ‘own your words/contributions’.

I’ve helped counsel previous employers and others on starting communities, and inevitably, the question comes up of ‘how much of this project should be public’.  My answer is always the same: "All of it should default to public".  Fred Wilson, a Venture Capitalist in New York, recently blogged about this, and I loved his take on it, which was informed by reading a pre-release version of an upcoming Jeff Jarvis book which quotes co-founders of both Flikr and Facebook on this subject.  I encourage folks to take a look at Fred’s post, but for me, the money quote was:

"The value of public discourse and engagement around content/information/knowledge vastly outweighs most of the privacy concerns most of the time."

Don’t get me wrong, there are plenty of times (and reasons) for content to be access controlled from free viewing, but I would argue those cases don’t constitute a community – they are more like project or implementation groups.  If your goal is truly to create a community around something, you need to trust the members of your community, and they need to trust you.  There is no surer path to the destruction of a vibrant community than to try and hide things that don’t need to be hidden.

The other area of trust which is a big deal for me is personal responsibility by the members of the community – specifically in owning your own words and contributions to the group.  Because of this, I have a very strong belief that anonymous posting in discussion forums has no place in communities.  I do run afoul of some of my colleagues at CollabNet at times for this view, and I do grant them there may be cases within project or implementation groups where this makes sense, but in general, requiring people to own their words and contributions is a critical piece of establishing trust in a community.

I believe there is a good reason the designers of our CollabNet SourceForge Enterprise tool decided the minimum permission needed to post to discussion forums is ‘a logged in user’.  By enforcing this with tools, and a diligent community manager who works to make sure that ‘anon spam’ doesn’t start to creep in, I believe the trust level of the community (and therefore, the productivity) is increased.

Interestingly, there may be some challenges with the SoftwareForge.mil piece of the forge.mil initiative in regards to ‘default to public’, but the owning of words/contributions has been pretty well settled – the Department of Defense isn’t big on anonymous posting. :)  We have had some interesting discussions with DoD regarding how we also bring reputation management into the picture for the forge.mil properties, and I think that is going to be the basis for some critical trust building going forward for this project.

My bottom line (from the ‘obvious statements department’):  If you don’t trust your community, they won’t trust you, and no amount of fancy marketing or public relations will be able to fix that.  I continue to encourage companies & individuals interested in utilizing the tremendous potential of communities to heed this.

Building Vibrant Open Source Communities

As promised, here is a quick rundown of where we are on the DISA forge.mil project:

• Very good progress made on PKI-enabling the CollabNet SourceForge and SVN products
• Initial drafts of site look & feel and content complete
• Initial draft of ‘Community Building Plan’ complete and ready for review

There is still a lot of work to do between now and the LOA (limited operation availability) date at the end of the year, but things are moving along.  Most likely the LOA period will last a month or so to shake out both technical and social/community issues, but we hope to be well along our way in February of 2009.

The Forge.mil effort continues to get positive reviews both inside and outside of the DoD, including this recent article in the Defense Systems publication.

I’m learning a ton about what community means (and where the challenges are) to the DoD, and the single greatest weapon in my arsenal is the lowly question.  I’ve learned to ask a lot of them to adjust the process of defining this community.

Thanks for listening – I’ll chime in with more updates as we progress toward site launch.

Update - Federal News Radio (WFED – 1500 AM out of Washington, DC) recently spoke with several influential government officials, including the CTO of DISA, who mentioned the forge.mil initiative.

Like any company in today’s world, CollabNet keeps pretty close tabs on sites or blogs which affect our products or our clients.  Recently, our CEO, Bill Portelli, forwarded along a link to the Department of the Navy’s CIO Office (DON CIO) blog.  This is related to the DISA project I blogged about previously, and the most recent post there (‘Trust: The Most Important Thing‘) contains a very telling quote:

"…while information technology affords us tremendous advances in transparency and information sharing, our organizational behavior and culture actually prohibit it."

This single statement struck a nerve in my mind about how organizations and the people that manage them sometimes equate the building or acquisition of tools with the building of communities and collaboration.  To most folks who have any knowledge of Open Source communities and their inner workings, this would seem to be clearly not true.  By the way, I beg indulgence of the non-technical folks reading this blog with regard to my title – the engineer in me still exists and the title above is a shorthand for ‘Tools do not equal Community, and Community does not equal Tools’.

In reading through DON CIO’s blog, it is clear that he comprehends that his organization needs to understand the path to collaboration, transparency, and information sharing does not go through which tools they choose.  It runs much deeper than that, and I’m thankful CollabNet’s senior staff and field organization generally understand that to be successful with a client, you need to take an approach advocated in the book Samurai Selling: The Ancient Art of Modern Service – specifically, making your client successful is the ultimate goal, and making them successful means considering how your tool/service is most beneficial to them.  In some cases, that may mean your tool isn’t the most appropriate, but maybe your service offering is, or maybe you have to integrate with a competitor’s tool to further develop the client’s community.  It also means you should be prepared to guide them in the best practices they can utilize to help steer their organization down a new path where the organizational culture/behavior can evolve to take advantage of the tools that enable better collaboration.

In the end, understanding you have to take into account existing company cultures, behaviors, and norms is critical to building a successful community, and making sure that is your primary goal as an organization, not the pushing of a tool at the expense of service, will help make you (and your client) more successful in the end.

Note – just found Richard Millington’s Online Community Building Manifesto, which speaks nicely to some of the things I mentioned above.