Complaining is a privelege, not a right
codeplex_mark
In politics, few things frustrate me as much as listening to someone complain about the current Congress and/or Administration, only to be told, when you ask them how they voted, "Oh, uh, I didn't actually vote. What's the point?" Surely one of the points is to recognize that you don't have a right to complain. Instead, you earn the privelege to complain by engaging and attempting to affect change.

Andrew Oliver, whom I quite like, and who has brought much needed sanity the OSI, as a recent blog post up titled To Microsoft, Open Source means "Windows Encumbered". He summarizes his complaints with Microsoft this way:
  • "They have not retracted their patent FUD against Linux.
  • They (a founding member of the BSA) did not speak out against the BSA/IIPA's attempt to have the US government equate Open Source with piracy and as anti-capitalist.
  • They continue to attack, with legal action or threats, any open source that competes with any of their core products.
  • They continue to hijack standards boards with "standards" that are encumbered by patent or platform constraints."
I think that his latter two points are false, or at least gross exaggerations. But truth isn't the issue here. My question is: which among us has earned the right to complain? Microsoft is a frequent target of criticism from the open source community, but criticizing alone is the lazy person's way out. The hard work begins when you adopt an approach of constructive engagement and actually roll up your sleeves to try and affect change.

No company has a perfect record when it comes to open source. IBM deserves credit as an early champion of open source, yet holds one of the largest software patent portfolios in the world. Apple has made important contributions to open source with WebKit,  yet I find their "walled garden" approach to technology so insufferable that I won't spend money on any of their products (and yes, boycotting can be a form of engagement). Microsoft certainly has a mixed record. 

But complaining about the lack of whole sale change isn't the answer. Just as IBM isn't going to suddenly stop patenting, and just as Apple isn't going to open their platforms to any and all programming languages of a developer's choice, Microsoft isn't going to transform itself overnight into a leading open source company.

If we want change, we have to work to make it happen incrementally. In the two years I have worked with Microsoft on a variety of open source initiatives, I have found them to be cautious but committed to being a more open company, releasing more software as open source, and interoperating more effectively with existing open source software. They are cautious because (a) no company opens up everything, and in this relatively new (for them) domain they are still feeling their way through what to open up and in what order. They are committed, because the last two years have seen tangible results:
  • Microsoft code committed to the Linux kernel
  • PHP running on Azure
  • The launch of the CodePlex Foundation, so that Microsoft and other such companies have a managable and understood path for making open source releases
  • The launch of the Foundation's ASP.NET Open Source Gallery, which is an important step towards fostering the kind of web application development eco-system among .NET developers that PHP has enjoyed for so long
Do I have complaints? Of course. I wish PDO was coming along faster. I wish Odata was better documented. Indeed, my list of complaints is endless. The difference is that I don't just shout my complaints to the heavens and then walk away feeling I've done my open source good deed for the day. I work to find the people inside of Microsoft that can make progress on the issues I'm concerned about, and I work with them to understand their concerns. I then do what I can to help those particular people move forward with their particular open source projects. 

That's how you earn the right to complain, and that's how you turn complaints into constructive criticism that actually yields results. As a community, we need to stop taking the easy way out and just bashing Microsoft. We need to help them move forward, incrementally, on the points where they are actively trying to make progress in their open source engagement.

Licensed for Innovation
codeplex_mark
I’m going to make a point about software licensing and open source by an albeit circuitous path.

One of my peak live music experiences was hearing Etta James in concert at Ironstone Vineyards. While she is more a star of my parents’ generation than mine, Ironstone’s small amphitheater nestled in the Sierra Nevada foothills was a perfect venue for her intimate, soulful sound, and thus an opportunity not to be missed.

My generation knows her voice best through her biggest hit, “At Last”, serving as the soundtrack for a long-running series of Jaguar TV commercials. What I did not know, that she hinted at in the concert, was that she had been involved in a dispute with Chess Records and British Motors over royalties from the use of that song in the commercial. Etta James was signed to her first recording contract as a teenager, and while Chess Records appeared to be no worse than other labels at the time in terms of the contracts it offered young artists, it was probably no better either. It is entirely possible that Etta James’ deal was less than scrupulous (see the book “Spinning Blues Into Gold”, by Nadine Cohodas, if you want more details of that time).

What fascinates me in this kind of rights dispute is that, regardless of the facts – facts that, at this point, probably no one clearly remembers or has well documented – it is human nature to instinctively side with the little guy. We naturally assume that British Motors and/or Chess Records must have somehow taken advantage of the young artist.

Consider, for example, a reversed situation: a young amateur musician performs a remix of a popular 50s car commercial jingle, turning it into a sizzling pop number, and posting it to YouTube where it becomes a hit video. If the car company then sues the young artist for failing to properly license the song, who do our sentiments side with? The musician, of course.

Our human nature to favor the little guy ignores the cognitive dissonance here: if we are right to fret that British Motors may have used a song without proper license, then the consistent point of view is to see that the artist in the second example has also used a song without proper license. We aren’t wired that way, though. Instead we get caught up in trying to figure out who is right and who is wrong.

And that’s the first point I’d like to make: being right often counts for very little in life. In fact, if you set aside questions of right and wrong, you can see that in fact Etta James and British Motors needed each other, and benefited greatly from each other.

On the one hand, British Motors couldn’t pay to have the kind of soundtrack written that “At Last” provided. Etta James created an innovative lifestyle statement for the Jaguar that would not have come about from trying to explicitly write such a piece. On the other hand, British Motors created an enduring audience for Etta James that has enabled her to be recognizable to new generations, and thus to continue to headline well past the time when many of her peers have retired from live performance.

My second, hypothetical example works the same way. The YouTube musician is creating valuable advertising for the car company that they couldn’t pay to create even if they wanted to. The smart company would encourage rather than try to suppress this musician.
Promiscuous use of intellectual property enables innovation to happen that would otherwise not occur, because talented people in one domain can have their work reused creatively in other domains where they don’t have the talent or knowledge to recognize the opportunity to apply their work. Too often we overlook this lesson because we get hung up on the right and wrong of how intellectual property is shared.
What does all of this have to do with software?

First, the distinction I've made here between focusing on "right vs. wrong" on the one hand and focusing on mutual benefit on the other hand actually captures the difference in emphasis between "free software" and "open source" pretty well. Free software is doing the right thing from one interest group's point of view. Open source is about advancing our collective self interest.

More importantly, open source is an innovation driver precisely because it sanctions the promiscuous sharing of intellectual property, and enables people with expertise in a particular domain to have that expertise reused wherever others can find a use for it. We need to remind ourselves of this, and we need to avoid applying “big guy vs. little guy” instincts in every situation.

On that latter point: Microsoft is getting into open source in a bigger way than it ever has before. That’s why it has released code for the Linux kernel, and that’s why it donated money to the launch of the CodePlex Foundation. Anyone who truly believes in the principles of open source has to believe this is a good thing, and indeed should be the inevitable outcome of years of open source success. Why is Microsoft willing to be more promiscuous with its own software intellectual property? It isn’t about doing the right thing. Its about doing the smart thing, and participating more fully in an innovation opportunity that other companies have enjoyed for years.

We’ll get a more innovative Microsoft, and a better open source community, as a result.

A Rest Stop on the OSS Turnpike
codeplex_mark
You know you are doing a poor job of explaining yourself when something that is so obvious that you take it for granted is a complete revelation to someone else.

Last week the CodePlex Foundation (CPF) sent "ambassadors" (me and President Sam Ramji) to ApacheCon to participate in one of open source's most significant annual events and to pay our respects to the Apache Software Foundation (ASF). 10 years is a great run, and the ASF has done some very impressive work during that time, work that has certainly inspired us in planning the CPF. Personally I give a lot of credit to Brian Behlendorf, who set the ASF on a unique path from the beginning.

In the early days of open source we all thought of flagship open source projects as succeeding in part because of the leadership of a single dominating individual. This tribal structure of a "benevolent dictator", or at most a "council of elders", seemed to be the norm, most clearly demonstrated in the case of Linux and Linus Torvalds. Unfortunately this model does not replicate well. If you have to have another Linus to have another Linux, then there isn't much you can do to facilitate that. You pretty much have to wait to get lucky. Now, I think there are characteristics of open source that make it easier to get lucky, but that's another topic.

Brian easily could have been the benevolent dictator of the Apache project. However, he wanted something different. He wanted a process and an approach to project governance that would liberate projects from their dependence on a single individual, something scalable, and repeatable, that could incorporate and adapt to changing best practices in open source software (OSS). Today we call this "the Apache Way". It is an end to end process for the software development lifecycle that any individual or company can adapt to. As we at the CPF try to figure out how to facilitate corporate participation in OSS, we've learned a lot from the Apache Way.

So why is it so hard for people to understand what the CPF is doing? Sam Ramji and I sat down with the folks from the ASF last week to talk about our mission and some of our specific approaches for fulfilling that mission. This led to their moment of revelation, and in turn mine.

At one point Greg Stein looked up and said -- you could almost see the lightbulb going off over his head, "So the CodePlex Foundation could be completely successful 5 or 10 years from now and have no intellectual property of its own?"

I thought about it. Now, I expect in 5 or 10 years the CPF will have some intellectual property assets, but it seemed perfectly obvious to me that that isn't a necessary condition for success. Why was it such a revelation to Greg? I think the answer comes down to this: we're in early stages, and have yet to have any projects affiliated with the CPF. We've only recently released our first draft of the project guidelines. So the legal documents we have posted so far talk primarily about how code can be contributed or licensed to the CPF. To the casual observer, that makes the CPF look like an intellectual property aggregator. And sadly, that's almost the complete opposite of what we're actually doing.

I start with an undeniable basic premise: Corporate software developers under-participate in open source projects.

What should we do about that? Jim Zemlin of the Linux Foundation has talked a lot, over the years, about the importance of paid development driving OSS, and increasing the number of OSS developers who are paid to work on OSS projects. At the CPF we are focused on the complimentary approach: getting more paid developers to do OSS development. So we are focused on a very different end of the problem. We are looking at companies where code by default is assumed to be proprietary, and it is assumed, by default, that the work of software developers automatically belongs to their employer. As companies recognize the need to increase participation in OSS, they recognize that they must change these default behaviors. The problem is they have no well-defined process for how to do so.

Some of the issues have to do with software development practices: how testing is done, how builds are managed, how dependencies are tracked, how bugs are tracked, how releases are scheduled, how security fixes are managed. All of this has to be adapted to new practices when a project becomes OSS. Some of it has to do with cultural practices. OSS developers simply have a different and more promiscuous notion about how to share ideas and drive innovation. A lot of it has to do with intellectual property: not just finding the right open source license, but finding the right contribution agreement to get software out the door and the right release agreement to enable developers to create software owned by someone other than their employer.

It can be a long turnpike from the point where a software idea is conceived inside a corporation until the point where it reaches its final destination as a released OSS project. Kudos to the ASF for trail-blazing this path and thinking about the whole problem end to end. But by their own admission, not every project is a fit for the ASF. They are a small, lean organization (frankly, so are we). Their core expertise is in the community and engineering side of OSS, and they do a great job of mentoring projects through the Apache Way. But they cannot, at the same time, have the expertise to accomodate a wide range of licenses or contribution agreements. They have one license, and one contribution agreement that projects must adhere to. We have an opportunity, at the CPF, to compliment the work of the ASF by focusing on the early stages of this journey and what it takes to get a project out from behind the corporate firewall. That means a more nuanced approach to contribution agreements, and contenancing a wider range of OSS licenses. But all of this is intended to make the CPF a pass through point. We are there to help corporations find the right home for their OSS projects and their OSS development work.

If we are successful, projecs may start at the CPF, but end up with the ASF, or some other organization. The key thing is to get projects out "in the wild" in the open source community, while doing so in a commercial-friendly manner. We are just a rest stop along the way, complimentary to, and additive with other OSS organizations. That's the real answer to Greg Stein's question, and that's how we aim to address the issue of under-participation.




Perspectives from Open World Forum
codeplex_mark
I've just wrapped up a busy week at Open World Forum in Paris. A good chance to renew old acquaintances, and make new ones. Here are a few thoughts on the many stimulating topics of discussion that came up during the week:

Software Patents. Michael Tiemann is as passionate as ever on the problem of software patents. After talking with him, I think he and I share a lot of common ground. The current worldwide approach to patents is a mess, and is not serving the original purpose of patent law: to give the inventor privileged rights for a limited time in a way that would incentivize innovation. I do not see that patents are, on balance, doing more to encourage innovation than they are to inhibit it right now. Large companies spend an enormous amount in money and dedicated resources to manage their patent portfolios, and for companies that derive relatively little of their revenue from patent royalties, there just isn't a lot of upside.

Does that mean we should move immediately to get rid of software patents? I guess I have two concerns:
* The problem is more than just software patents. I guess I hadn't really thought this through until I started working with Andrew Hessel on his "Open Source Biology" essay for Open Sources 2.0. Thanks to Andrew I see the patent problem as pervasive to the whole world of intellectual research, not just software. I don't think Michael would disagree with this, but thinks that that the software patent challenge is more than enough for him to tackle. The problem is that, if the issues aren't unique to software, then they can't be solved exclusively for software or we're just breaking the system further.
* You still have to solve the innovation problem. Saying that patents don't have a net positive impact on innovation is not the same as saying they have no impact. Patents are an incentive system for innovation. If you are going to remove this system, you have to propose another. Frankly, I don't know what the alternative is, and I haven't heard one from Michael. In a way, this cuts to the heart of the difference between Free Software and Open Source. I have never accepted Stallman's argument that Free Software provides a way for developers to be compensated for their work.

Democratization of Data. While everyone is excited about the capabilities that cloud computing might deliver, and about how much of cloud infrastructure will be built on open source, I also heard a lot of concern expressed. The Cloud has the potential that puts one more layer between the user and the open source software on which they are dependent. Already we are giving up our data to so many large corporate entities in exchange for the "services" they provide. The Cloud threatens to institutionalize this as a social norm. From the first PC to open source, open computing has done so much to democratize our participation in the digital world. Personal data looks like the next battle for open computing, and the Cloud may be the battlefield.

Open Source Communication and Education. I was a little taken aback at how many companies and open source projects in Europe complained about the wide gulf between technical decision-making and business decision-making. This was a very common theme at the Open Source Think Tank workshop, for example. Developers bemoan the lack of understanding that customers or their own business executives have about what is possible, what is hard, and what is easy in open source. And business people bemoan the way developers scoff at the business considerations that at times trump technical considerations. Sadly, I don't think this is a uniquely European problem. I've seen both sides of this first hand doing product management for large companies in the U.S.

The silver lining is that this issue really re-affirms for me that the CodePlex Foundation has a place to add value to the open source eco-system. There are a lot of obstacles that put a barrier to wider participation by software companies in open source projects. Some of those obstacles are still as simple as needing more of a shared understanding. That's certainly a place where we at the Foundation can help.


The Three Camps of Open Source
codeplex_mark
Matt Asay has a typically thought-provoking post up titled "Free software is dead. Long live open source". He extolls the virtues of open source pragmatism, and adds his voice to other recent critics of the more ideological Free Software movement. While I like much of what Matt has to say, and I like all of what he forces us to think about, I want to take issue with some of his characterization and remind folks of the full historical context at work here.

Matt poses a typical contrast between pragmatic open source and ideological free software, as if these are the end points of the spectrum, and as if open source emerged out of free software. Specifically, he says:

"There have long been two camps within what we typically refer to as 'open-source software.' The first is led by free-software advocates like Richard Stallman (who, importantly, largely eschew the term 'open source' as not being sufficiently concerned with freedom), while the latter is led by no one, but was formally organized in 1998 by Tim O'Reilly, Eric Raymond, and others in Silicon Valley."

Actually, while the term "open source" was not coined until 1998, the roots of the movement go back at least as far, and evolved independent of Free Software. The real contrast is between Unix and GNU, as emphasized by GNU's recursive meaning as "GNU's Not Unix". And to some extent the contrast is between Berkeley and MIT.

Kirk McKusick nicely laid out the history of Berkeley Unix in his essay, "Twenty Years of Berkeley Unix"  for the original Open Sources volume. (I'll note that volume was published ten years ago, making it now thirty years of Berkeley Unix.) Part of Kirk's point is that the idea of "freeing" Unix goes back to the late 70s, and that the Berkeley Unix approach to "freedom" always meant a fairly unrestricted way to use the software, whether in an academic context (UC Berkeley), or a commercial context (Sun Microsystems).

While the term "open source" was actually coined by Christine Peterson of the Foresight Institute, the three people most involved in first pointing out the need for such a term and then evangelizing its importance were Eric Raymond, Larry Augustin (then CEO of VA Linux Systems) and Tim O'Reilly. What's interesting is that Tim came at this issue very much from a Unix perspective, not a Free Software perspective and not -- I'll point out the distinction shortly -- a Linux perspective. Let me put this in context from my vantage point as an editor at O'Reilly at the time. By the time the term "open source" was coined, O'Reilly's "Unix in a Nutshell" had already sold about 10 million copies. Unix was very big business for O'Reilly, and the importance of Berkeley Unix's (by this time the three branches of Free BSD, Net BSD, and Open BSD) pragmatic approach to relatively unrestricted use seemed obvious.

What followed from the coining of the term was the very first Open Source Summit, held in Palo Alto. One thing that was fascinating to observe was that there really were two distinct camps there. Larry Augustin made sure that the Linux camp was well represented, and Tim O'Reilly made sure that the Berkeley Unix camp was well represented. And in fact these were two groups that previously had had very little interaction. The Linux guys were younger, more brash, and full of dot-com enthusiasm. The Berkeley crowd was older, more subdued, and saw the dot-com boom as just another cycle. That these two camps came out of that meeting seeing common cause and being willing to work together is a real testament to the perseverance and insight that Larry and Tim had. That they are two distinct camps has been largely obscured by the passage of time, and glossed over not just by Matt Asay but by many others.

Because who was not at that first Open Source Summit? Richard Stallman was not there, nor anyone else of stature from a purely Free Software perspective.

It's human nature to think in simple dichotomies: Free Software - GNU - GPL vs. Open Source - BSD License. But I would argue that there are three corners to this triangle: Berkeley Unix (and Apache, Sendmail, Perl, and all the other products of the UC Berkeley camp) vs. Linux (and PHP, MySQL, and all the other outgrowths of the dot-com era) vs. GNU.

Linux, in many ways, is the paradox: the most commercially successful piece of open source software, and yet licensed under the GPL. The FreeBSD guys, for example, may well scratch their heads and wonder why their equally good operating system under a more permissive license has enjoyed less commercial adoption. Meanwhile the Free Software guys rail against companies like Google that use Linux commercially without having to release their own software because technically a website isn't distributing software. The press likes to talk up GPL v3 as a shot across the bow of Microsoft. My own suspicion is that it is more a shot across the bow of Linux. Stallman can call it "GNU/Linux" all he wants, but that doesn't make it so. Linux is the third camp, not part of the Free Software camp. Not surprisingly, Linus has not taken the bait and has opted not to adopt GPL v3.

Maybe the real lesson is that the magic isn't in the license, or in the software. It's in the willingness of camps with contrasting interests to collaborate. When academics, entrepeneurs, and grass roots developers collaborated in the 90s remarkable things began to happen. Sadly, that kind of collaboration is still too much a "manual" exercise: dependent on the personalities involved, and the circumstances that bring them together. Ten years later, we need to be moving to more of a process, codified by a set of best practices.

One way to approach the problem may be under the auspices of an open source foundation, one that is dedicated to understanding and capturing those best practices and processes across projects, and across commercial open source endeavors, instead of trying to advance just one area of endeavor. Certainly that's part of what we aim to accomplish with the CodePlex Foundation.


You are viewing codeplex_mark