As Jeffrey Hammond, of Forrester, blogged recently, Subversion is the overwhelmingly predominant version control system today. Yet if you read the open-source blogs and discussions, you see loads of growth in the "Distributed Version Control Systems" (DVCS), such as git, Mercurial, Bazaar, and the like. What's going on here?

There's an interesting even just now in the Linux kernel that sheds some light. This week, according to Greg Kroah-Hartman, some Google-contributed, Android-related code was removed from the Linux kernel. The reason: the code in question is both incomplete on its own, and specific to the Android device. Either of these properties makes it constitute a "fork," and in this case there seemed no prospect of ever healing the fork.

Now, you might think a "fork" is something that happens to the code, and certainly that's part of it. But as Kroah-Hartman points out, code-forking happens all the time. The problem here is that "no one cared about the code, so it was removed." This doesn't mean no one cares about the code that's going into Android--certainly not! It means two other things:

• No one was taking care of the code that had been contributed into the Linux kernel tree
• No one was consuming, using, extending, or applying the code for new purposes

It had been, as the phrase is, "thrown over the wall," and left.

That--abandonment--is a big problem for open-source code, both in that it's harmful and wasteful, and also in that it's common. But it's a cultural problem, not a technical one: there's no claim that this was "bad" code, just that it was a dead end.

Open-source communities are actually pretty robust against this sort of harm. This event illustrates one such defense: if it's dead, dump it. Another commonly applied defense is simply to let projects die when no one cares: the notorious numbers of open-source projects that never got anywhere are actually signs of health: the open-source community has a powerful defense called "cheap failure," that allows ideas to start out sounding good, then peter out harmlessly. One of the cool things about DVCS is that it's very easy to start a fork, very easy to reintegrate it if you choose to--and very easy to chop it off and toss it away if it ends up a dead end, as we see here.

But if we recast this whole experience into an enterprise context, it begins to look very different indeed. The essential difference is that failure within an enterprise is never "cheap." If the Linux kernel community, including Google/Android, were an enterprise, then all the work that has been spent on this fork would have come out of corporate wallet, and the decision to toss it would be a recognition of wasted resources: salaries, equipment, time, plans, marketing, process--endless kinds of costs, sunk with no payback.

The great contrast between the low cost of open-source failure, and the high cost of enterprise failure has far-reaching effects, even down to details like tool choice.

• An open-source project can usefully tell prospective contributors "clone the tree, work up your idea, and get back to us when you have something to show," because there's no cost to the project if the idea never bears fruit. An enterprise, however, does have such costs, and at the least has little incentive to allow that sort of work style.
• An open-source project can allow parallel, semi-independent, persistent forks, such as the several Linux distributions: as long as there are enough people (whether sponsored or volunteer) interested in working the fork, as long as things stay controlled enough that work can be merged back and forth, there's no problem. But an enterprise may need to match its centralized budgeting and resource management with some centralized supervision, planning, marketing, and management: making it easy to disappear from the radar is not a good thing.

And that, I think, is at least part of why the centralized Subversion model remains so strong.

From MASSForge, the software collaboration environment for the Commonwealth of Massachusetts, comes a great add-on to your CollabNet TeamForge site, the Calendar linked application. Better yet, this is an open-source project, hosted on our public site, ctf.open.collab.net, so if you see some improvements you'd like to make, you easily can—as well as contributing them back to the project, if they might be generally useful.

The application deploys easily into any modern Tomcat server. With that plus "Linked Application" configuration into your project, you're off and running. A new tab will appear in the project's tab-bar:

 

... and Tasks entered in the project's Tasks tool will be displayed in the calendar:

As with any good open-source project, there's a wiki with installation details, and a full suite of discussions for Announcements, Help, and any Installation Issues (none reported so far—be the first!)

You can check the project out from Subversion, or download the latest release from the File Releases area.

The recent guidance from the Department of Defense (DoD) issued by Deputy CIO David Wennergren (Oct. 29th) is certainly a milestone for open source software.  It states that the DoD should consider open source software on equal footing with commercial software offerings.  While this in itself is an important achievement, the guidance goes further to reference that software source code and associated design documents are “data”, as defined by DoD Directive 8320.02.  The inclusion of this reference could be seen as a subtle point, but one possible implication is that software source code should be considered a contractual deliverable.

The lack of access to source code and clear government usage rights have been major impediments undermining DoD wide software reuse initiatives.  Simply stated, no source code, no reuse.  In my view, the new guidance can be seen as an initial step in DoD acquisition reform that could enable large amounts of software to be shared and reused across the DoD.  The reuse and sharing of software is already enabled by the collaborative software development environment at Forge.mil, as operated by the Defense Information Systems Agency (DISA).  Policies that increase the government's access to source code can only help to foster the success of such initiatives.

 

As tax payers, any policy that effectively enables software reuse, regardless of whether it is developed under open source license or not, should be received as a positive step.  The net result might be that the DoD actually stops paying and repaying for the same software to be developed over again.

One of the stalwarts of Subversion, Ben Collins-Sussman (a Googler and former CollabNetizen), remarks

Not that this should shock anybody, but in case you didn’t know, now you do. The overlap between Apache and Subversion communities has always been huge since day one — with essentially identical cultures. We’ve talked about doing this for years. It means we can finally dissolve the ‘Subversion corporation’ and let ASF handle all our finances and legal needs.

via blog.red-bean.com

Observers may not realize just how true this is. This announcement is a great thing for Subversion, for ASF, for CollabNet, and all other companies who depend on Subversion for their work and products, because it means that the supporting details are in good hands, and the contributors can get back to their contributions. But in another sense, it's about as "un" an event as it well could be.

One anecdote from the press conference yesterday really drove that home for me. John Mark Walker, of OStatic, and Paul Krill, of Infoworld, asked how this change will affect Subversion developers and users. Everyone around the table leaned forward to answer, but the winner was the current President of the Apache Software Foundation and a major Subversion committer, Justin Erenkrantz, whose response began "In the Subversion community, we've always operated in the Apache way." This was echoed and reinforced by Sander Striker, past President of the ASF and another major Subversion committer, and Greg Stein, several-time past Chairman of the ASF and one of the most active Subversion committers of the moment.

So there you have it: if Presidents and Chairmen of the ASF think of themselves first as members of the Subversion community, how much change could we really be talking about?

A while ago, I pointed out that many discussions of open-source related business models are leaving something out: infrastructure. A lot of people have asked me to explain the difference between "open core" and "open infrastructure"--don't they both mean "open-sourcing the basic stuff"? Well, to some extent they do, but the difference is real, and apparently even more significant than I had thought.

"More significant"? Looks like: Kim Weins at OpenLogic provides some survey results that indicate that customers aren't so happy with the "core vs. complement" choice. And apparently, they're not alone: the much discussed decision by the European Union, to look more closely at the Oracle-Sun merger with an eye to protect the open source MySQL product has been widely decried as a misunderstanding of open source, but may really be just another expression of this same discontent. Matt Aslett of The 451 Group has made a good case that the EU's concern strikes to the heart of the distinction I'm trying to draw. The essential concern is that the open-core approach can mean that the proprietary sponsor of the open-source project can delay, divert, or simply out-pace the community version, making it not really viable. When that happens, you're perilously close to "faux-pen source," something that pretends to be open, but is only viable commercially.

In contrast, the "open infrastructure" model identifies a viable, useful product to be created as an entirely open-source project, and then used to build something fundamentally different. The Apache community has many examples; I think this model may have been an Apache invention. To pick one specific example (and one I can speak most about, as I'm involved), let's talk about Subversion.

Subversion is an open source project. It's a completely open source project: the whole product is available under an open source license. CollabNet (yep, that's us) is, and always has been, the primary sponsor of Subversion, contributing around 25 percent of the labor, over the years, as well as a major portion of the community leadership, and the grunt work of release processes, road maps, and project management. 

I don't think there's any doubt but that there would be no Subversion, and no Subversion community, without CollabNet, because of the way the project began: Brian Behlendorf, founder and then-CTO of CollabNet, hired the team, gave them an office ... and then made them work as an open-source project, in the open, instead of an internal development project. Just as clearly, CollabNet did this for business reasons. But the Subversion product, produced by the Subversion community, is in no way "crippleware" merely intended to lure you in to the CollabNet commercial "real" product. Slipping down that slope is the great risk of the "open-core" model, where your profitability depends on a narrow feature advantage over the open source alternative. It's a risk the EU appears to be concerned about. 

CollabNet chose not to follow that path at all: Subversion is Subversion. Any Subversion is all of Subversion. Instead, CollabNet provides another, larger product: CollabNet TeamForge, a product that would be much less valuable without Subversion (which is what justifies our investment), but clearly a different product.

So what's the difference? You still don't see it? OK, maybe it's a matter of degrees. Maybe a metaphor would help. Let's say you want to be a car manufacturer. You can open-source the production of your tires, and build a car that uses those tires. That's "open infrastructure." I don't guess there's a lot of "open source tire manufacturing" going on, but I'm pretty sure that something like 100% of car manufacturers at least "out-source" their tires! It's viable, it works, everybody does it. It's a business model.

But if your automobile business model is to "open core" everything but the paint, if your value-add is only the paint ... well, then you're going to see some paint-thin profit margins, too.

This weekend I attended the Community Leadership Summit in San Jose. Before it even started, I had an interesting discussion with Jack Repenning and a man who was investigating various community models for a homeschooling organization he's working for. As we talked about the needs of the parents of homeschoolers, I realized how much they had in common with open source community members:

• They are joiners and have need of connecting with other parents like themselves
• They do not want an overt governing body controlling the way the community interacts
• They have need of shared resources and discussions
• They want to stay away from institutionalized or corporate rules and pressures, and instead want the community members to have roles emerge organically

There are likely some similarities I'm missing here, but I realized in this discussion that these types of communities can benefit from the open source community model. In an open source community, it's important that creativity is encouraged and unbound, that community members are treated equally, and that any roles assigned are appropriate and emerge out of needs rather that what an official overhead dictates. This type of community is self-regulating for the most part, if not entirely.

The parents of homeschoolers, and many groups like them, are rejecting conventional methods of education, but that does not mean they don't have a driving need for support, communal togetherness, or collaboration.They do join groups, parenting, educational, as well as many others, but they want to avoid the school "feel."

Additionally, I can see how a project model and platform would work for homeschoolers and their parents. Homeschooling often involves collaboration similar to software development. Needless to say the Subversion and TeamForge platform would be ideal so that children could work together on various projects, keeping all versions of a project and adding to it, while parents could make use of collaborating on resources, documentation, and discussion forums.

Both the open source community model and the CollabNet platform and tools would work well for the homeschooling crowd, and no doubt many other non-developer types.

I'm noticing more communities wiggling out from "the man" and opting for an open environment in which community drives and guides itself. Everyone seems to be tiring of corporate or institutional pressure and dictates. I think we'll be seeing the open source community model becoming more the norm than not over the next few years. And it will be interesting and fun to see what kind of creativity emerges from these communities of free thinkers.

 

Businesses and governments spend a lot of time, effort, and money attempting to do two things with social media: a) block it completely, or b) allow it, but attempt to monopolize it as a sales channel. Usually in the latter case, it eventually comes down to that dreaded three-letter acronym: ROI. Yes, 'return on investment' - how does allowing my employees to be part of this burgeoning new networked world help my business sell more things or make my people more productive?

The answer is... it probably won't (at least not directly), which might come as a shock to most business and government people who have been 'sold' on social media. You see, I think that way too much focus goes into trying to quantify the benefits of social media, when in point of fact, they are almost impossible to measure. How do you measure the productivity gain of having your talented employees asking questions, sharing ideas, and yes, occasionally ranting on Facebook or Twitter? Answer: You can't (directly). However, when one of your employees seeks information on a particularly tough problem they are having, or asks for a contact into a potential new business venture, and gets multiple responses (some of which are very good), there is invaluable knowledge transfer happening! Chris Brogan had a great take on social media metrics in his latest blog post, to wit: "...Make the numbers matter to the business, not to what social media does and doesn’t cover." He's right on the money here - instead of making up metrics specific to social media, focus on the outcomes that you are already trying to measure for brand outreach or worker productivity. Trying to directly measure social media ROI is a dubious proposition at best.

The Open Source world has learned the lessons of 'social media' well, even if they aren't directly using Facebook or Twitter (and in some cases, they are!). Social media makes it easier for 'communities' to build up (or tear down) dynamically and provides a near real-time professional zeitgeist. Yes, I know, I've used that description in previous blog posts, but it really is the most apt word that can be used for what social media, properly used, can bring to the party.

Let's look at an analogy to an 'older' technology - email. How do you measure the benefit of having your employees able to email anyone (yes, including Grandma Fern for her cookie recipe)? I don't believe you can measure this, but considering that not having email access at most companies is pretty much like not having electricity, we've clearly gotten past the conceptual hump on that technology. To those critics who will argue that Twitter/Facebook, etc. take too much time away from employee productivity, I'd have to agree, IF you don't do a good enough job of screening your potential employees. If you hire people who can't be trusted to professionally manage their time in the social networking arena, unfettered email access is surely going to be a problem as well.

Let's focus for a minute on the monopolization of social media for the marketing/sales side. I'm not at all suggesting that these avenues aren't a good option for sales/marketing activities. However, if that is the sole reason you are using them as a company, you'd probably be better off spending your money on traditional advertising campaigns. The benefit you get from being involved in Twitter or Facebook as a company is that your brand is seen as more 'human,' and you get a new way to interact with your current and potential user base in a two-way fashion, as opposed to pushing 'messaging' at them. People who are already part of these social networks expect a conversation with your company, not another one-way push of sales information.

So, does all of this mean you and your employees shouldn't be a part of this new frontier? Absolutely not - there is clear evidence, albeit anecdotal, that participation by companies and employees in social media improves knowledge transfer and overall brand awareness. Given that the 'investment' is mostly in time (the technology piggybacks on your existing network infrastructure), and if your staff are professionals, you can expect to have happier - and generally more knowledgeable - employees, as well as customers.

Remember, business analysts at one time thought email was going to be the downfall of the business world, but it has instead become a critical tool. While not there yet, social media systems as tools are well on their way to following suit.

"Open source development" is vastly more about the openness of the development that the openness of the source. This can be confusing, and may be at the root of some of the classic first-encounter confusions.

A great exploration of the point has just surfaced in a totally non-code area: O'Reilly Media and authors are pioneering an "open source publishing" system. They're really excited about the results, and you might be surprised at how thoroughly their success parallels the successes of the best of open-source software.

Basically what they've done is to make early drafts of their books available on line, with an in-line comment system. As each draft goes out and draws comment, they incorporate the feedback into the book. The authors remain the authors: while I'm sure they'll find some way to acknowledge their over 700 reviewers, they're not changing the names on the cover. This work is most similar to the "Commercial Open Source" model discussed in my "Open core, open complement" post.

But whatever the structure, the open sourcing is a resounding success:

• 7000 comments
• 700 reviewers, where most technical books might have only 2 
• comments from every relevant demographic, from highly experienced to neophyte 

Have these reviewers provided actual publishable content? Probably in some cases, but many also have contributed by comments as vague as "I have no idea what you're trying to say, here." They're all valuable; they all save the authors tremendous effort; they all make the result a better book.

Every open-source software project needs this kind of contribution: real and potential users guiding the way. How accessible a given project is to actual code contribution can vary widely, but your potential-commenter community is always just exactly as large as your potential-customer community. Get them involved!

As I sit here in the offices of CollabNet on a Friday evening, wrapping up final tasks before heading to Anaheim next week for the DISA Partner Conference, I'm heartened by news that we received about an hour ago. The Forge.mil system has officially been granted IOC (Initial Operational Capability) status by DISA. This may not mean much to some of you reading this, but suffice it to say it is a huge step forward in fielding a set of collaborative environments to improve software development at the US Department of Defense.

We now are 'officially open for business' (with the initial 'SoftwareForge.mil' offering). This does not mean that the work is over however - it is only just beginning. We expect that after (or probably even during) the conference next week, we'll be getting a deluge of new users and project requests on SoftwareForge.mil. Additionally, we know there is pent-up demand for the ProjectForge.mil capability (the same toolset as SoftwareForge.mil, but specifically designed to allow private collaborative projects within DoD).

When we started development of what has become our IOC launch back in October of last year, I don't think any of us truly realized the huge interest we would be generating with this effort. As we prepare to present the Forge.mil story at the conference, including a panel session I'll be a part of, I'd like to thank our colleagues at DISA & Navy SPAWAR for guiding us through the complex process of launching the site while keeping an open mind to a new way of doing things. I know I've learned a ton about how software development in the government works, and I hope we've been able to bring a unique perspective on how Open Source collaborative projects can work in such an environment.

For those that may just be joining this blog thread on my Forge.mil updates, feel free to check out the slides and video replay of the 'Introduction to Forge.mil' webinar we did several weeks ago. It should give you a good overall feel for where we are trying to take this effort. We also welcome your comments, questions, and feedback on that direction as well.

And with that, I'm going to head off to pack, and hope to see some of you at the show. Oh, and yes, I'll be sneaking in some 'Mickey Time' at Disneyland the weekend after the conference... I couldn't go all the way down there and not pop in to see my favorite mouse and his cohorts!

I'll be tweeting from the show as well (you can follow me @guyma on Twitter), and will have a wrap-up blog post when I get back. I'll see the rest of you in a couple of weeks...

There's a certain amount of consternation about as to why there's so little up-take on the Affero GNU Public License (AGPL⁽¹⁾).

• Stephen O'Grady, of RedMonk, recently cataloged AGPL adoption at around one in a thousand open-source projects. His explanation? Open-source projects don't need the extra protection (or at any rate, don't perceive the need).  
• Matt Asay suggests no one really wants to change source code, anyway (or at any rate, to contribute it back). 

   What I think we actually have going on here is the growth of open-source products beyond their original market: those competent to modify them. You can see these roots of the open source movement as recently as last week, when Richard Stallman criticized Amazon's Kindle e-book reader for using closed-source software:

    The reason that Amazon can turn off the screen reader capability is

    that the machines use non-free software, controlled by Amazon rather

    than by the user.  If Amazon can turn this off retroactively (does

    anyone know for certain if they did?), it implies the product has a

    dangerous back door.

True enough, if you're the sort of person with the time and talents to change the code to close the back door. Academic, at best, if you don't have that time or those talents. But if you view hacker freedom in this (what I can only call) moral light, then sure, extending the protections of the GPL to new deployment styles makes sense.

But the open source community has developed several models other over time. The Apache Software Foundation, for example, pioneered open source techniques as simply a more effective way to create software, through cooperation and collaboration instead of competition. The Apache License does not forbid you to use, combine, or redistribute the products, so the AGPL's tightening of redistribution rights is uninteresting. 

Similarly, some have adopted a so-called "dual licensing" strategy (MySQL perhaps most famously), where their product is available under GPL for non-commercial purposes, but not for commercial ones; for that, you need some other, more conventional commercial license. Matt Asay (mentioned above) has frequently presented his product, Alfresco, as being open source primarily in order to achieve adoption and market penetration, which seems to be the common thread for all dual-licensing strategists. For these licensors, the extra protections of the Affero clause don't really apply, either: while they might well not want their code used, gratis, by some hosted service, as a practical matter that would probably be commercial application, and already covered by their system.

What you can see here is that the Affero clause reveals some core differences in open-source community  motivations. If you're considering contributing to or starting an open-source or inner-source project, it's something to think about: are you a missionary out to save the world, or are you just trying to get some work done? Are you using the techniques to create more and better code, or for market reasons? Your license, your community management, and your expectations should all be aligned.

---

1. In brief, the "Affero GNU Public License" adds one clause, that extends the base GPL's requirement that your product be open-source if you use GPL'ed components in certain ways (what is sometimes called the GPL's "viral" clause). The "Affero Clause" extends this "virality" to uses in hosted software (whereas the base GPL only applies it to software that is "distributed").