Category: Syndicated

Snoopy-dancing on SCO’s Grave

John MarkLeave a comment

I just got the news of SCO's passing - well, ok filing chapter 11 bankruptcy under the guise of "protect its assets during this time." One can't help but think that they see the writing on the wall and are doing this in anticipation of a slew of lawsuits. A lot of people have lost money on SCO and might consider their statements over the last 4 years to have been, shall we say, less than fact-based. That and the fact that they've bled cash for years and can no longer sustain their current loss rate.

This is an important day, and it's a time to reflect on the actual fallout from the case. One thing we must keep in mind is that the actual case SCO brought forward in court was far different from the case they fought in the press. Their press statements for over a year were all bravado about how Linux infringed on their IP and they might have to sue all Linux customers... or some such. Recall how some Linux users actually bought a SCO license, including Sun. If Sun were ever to meet this issue head on and describe why they helped fund SCO's war chest, now might be the time to do it. And, of course, you can't discuss this issue without also bringing in David Boyes, Microsoft, IBM, Novell, the BayStar Capital fiasco, Sun, Groklaw, Pamela Jones, Maureen O'Gara, Darl McBride. Shoot, I could write a 5-act play with all that stuff 🙂

The number of personalities involved is truly epic - but was the end result so epic? Well, I tend to think so, for precisely the same reasons that others think it wasn't epic. It was epic because nothing happened. It was epic because it showed 2 things: 1. Linux customer adoption would continue with or without SCO's support and 2. Linux != open source. For the former, we may never know in real $$$ whether or how many companies refrained from using Linux as a result of this series of lawsuits. For the latter, we saw many many more open source technologies rise in prominence even when the SCO litigation may have been in doubt in the minds of some.

So I will think about what has transpired, read Pamela's (deserved) gloating on groklaw, and wonder if others will follow in SCO's footsteps. I can't imagine that this is the last litigation we'll see of a successful open source project. In fact, I can see the success of various open source projects making them large targets. One thing is clear - whoever sues next will glean much from this episode.

Open Source Macro vs. Micro – Part II

John MarkLeave a comment

As I mentioned in my previous post on this topic, Open Source and open technology trends continue to swing in one direction (up and to the right). Along this ever-growing open technology spectrum lie various projects and companies who hope to gain a competitive advantage through some type of open collaboration initiative. Within this spectrum lies a subset of this group that I call the Open Source ecosystem. I've mentioned elsewhere why more companies are gravitating towards an open technology and Open Source model. In this document, I'll follow-up on my last post and explain in more detail what it means for a project to win over the hearts and minds of an intended audience. The basic question may be phrased as thus: why does "joe user" or "joe developer" gravitate to one project or technology over another.

Note that a given online community comes with its own biases, ambitions and desires, and these wildly differ from one online community to another. The community type with which I'm most familiar and the one that defines the context of this post and others, is the Open Source type of community, with its demands that projects and companies live by a codified set of rules as defined by the Open Source Definition. The Free Software community also lives in close proximity to, if not within, the Open Source ecosystem, given its similar requirements and moral framework, although these could be described as more stringent than Open Source. This is the context with which I'm most familiar.

It seems that there are two basic attractors that define why someone may gravitate to a specific place on the internet and call it 127.0.0.1. One is the technology basis of a given software project, and the other is harder to define. For lack of a better description, it's the sense that this particular project or group of people is not simply trying to make better technology but also trying to make this a better world (I can hear the groans now... bear with me). I'll simply label it as the cultural attractor. So we have two attractors: 1. technology - ie. is your stuff up to snuff? and 2. cultural - ie. technology is nice, but where does it fit in the larger context of the world?

The Technology Part

You might think that the technology attractor is the easiest to define: it's not. There is a ton of good techology that makes a poor basis for an open source project. OpenOffice.org comes to mind - it has many thousands of users, but the fact that there's any collaborative community at all around that project is mostly due to the sheer willpower of Sun and the OpenOffice.org community leaders. This is not meant as a slam on OpenOffice.org - I just want to point out that it was never very hacker-friendly. It wasn't the type of project that a developer or scripting guru could do much with. A project like KOffice or even Gnumeric would probably be much more fun for your average "joe developer".

To me, what defines a project ripe for Open Source collaboration is one that's not quite feature-complete or fully formed, has many interfaces to allow for collaboration from any developer's preferred language, and is broken into small, modularized bits. The Linux kernel is a good but not perfect example - it's a great starting point for the various Linux-based distributions to add their own kernel improvements, and it's modularized enough to allow developers to focus on one particular aspect. Firefox is another good, but not great example - the developer interfaces have allowed for some amazing extensions, and the project has been the basis for a variety of commercial software efforts. These three aspects can be summed up in one word: hackability. If a project is hackable and gives developers room to play, while also giving users a real platform do to stuff, then that's a good start.

As I noted in my previous post, however, the technology part is not the sole definer of success or failure for Open Source projects - there's also a cultural aspect that is often poorly understood and yet almost but not quite as important as the technology itself.

The Cultural Part

The basic question here is: will I feel good about myself if I devote time to this project? This is the part where many projects and companies fail to capitalize on their community. This type of cultural attractor could be as simple as the personalities of the project leads and their abilities to inspire current (and future) collaborators. Or your project collaborates with groups only indirectly related to your core technology. Or perhaps you wish to contribute to some organization involved in information rights. All of these can contribute to the essence of your community feel.

Some companies have more tolerance for risk than others, so for them, engaging in activities which may or may not generate direct revenue is worth doing if they can see real benefits. My point is that this type of activity isn't all that risky, and it's not actually very expensive. Sponsoring user groups and user group-driven events is pennies on the dollar compared to traditional sponsorships for formal trade shows. Putting your name on the list of sponsors of a well-reasoned political initiative, such as getting governments to use open formats, only seems risky at first glance. Contributing to groups that aim to protect the rights of developers and users also gives off a nice warm glow - and would it be too cynical of me to note that any SEO professional *loves* incoming links from those types of organizations? There's a lot to be said for this type of activity and, frankly, I often wonder why more companies don't do it. The poster child of cultural attractors? Well, stay tuned for that one 😉 This post is getting a bit long, but in the follow-up, I'll list some specific things that companies have done to engage with grassroots Open Source-related groups, and what happened as a result.

What is Software Commoditization?

John MarkLeave a comment

I was reading Stephen Walli's blog, as I often do, and came across one referencing a presentation by Brent Williams on the topic of "Open Source Business Models: A Wall Street Look at a Wild 2006 and the Prospects for Even More Fun in 2007", with the slides (PDF) posted here.

What particularly caught my eye was Stephe's comment about Williams' "tear down of the commoditization myth." After reviewing the slides, I see that Williams truly possesses a great intellect and analytical ability. I can only hope to see him make a presentation in the near future! However, I get the sense that when I use the term "commoditized" to describe cheap software bits, it doesn't exactly fit the term that he's tearing down in his slides. I would seem then that when he debunks the idea of commoditized software, we're actually talking past each other and arguing purely on semantic grounds.

My view on commoditized software has been that, with the proliferation of coders and more code distributed throughout the massive expanse of the internet, we see an emergence of low or no-cost programs, libraries, and other bits of code that other developers and IT professionals can latch onto, either as is or stuffed into a complex composite application. This model treats bits of code as reusable parts that a decent code jockey can then make use of, so that developers can bypass the grunt work often associated with coding and jumping almost directly into the more interesting work. The end result is a cheaper development process and, IMHO, downward price pressure.

This model assumes a bunch of stuff: 1. that the code is pluggable enough to be inserted into other software and 2. that it's of decent enough quality. Often, either or both of those statements are not true, which takes the developer back to square one of building everything from scratch - or does it? Williams' slides really made me re-think the whole term commoditization: is it the code or the knowledge of the problem's solution that has been commoditized? We can all imagine software as a pluggable commodity, but what if it's not the software itself, but rather the knowledge gained by seeing another solution and using the logic as a starting point?

While it's important to note that "commodity software" doesn't fit the traditional definition of commodities, I'm not sure how useful such word-splicing is. I suppose it's better instead to come up with a word that can describe "software depressed in price by an abundance of implementations AND implementors." I would actually argue that it's the latter that's of primary importance here - after all, doesn't the potential of others to implement a feature set depress prices just as much as an actual implementation? Do all ISV's build in this "fear of the near future"? And with the internet, that fear mushrooms when you think about the prospect of hundreds of knowledgeable people around the world *potentially* working on similar solutions as you.

Compare software and science - would you argue that the theory of relativity is a commodity? Probably not, but it's a known quantity. The practical aspects of relativity have been known for some time now, although the theoretical realms may still be under discussion - I actually don't know, not being a theoretical physicist. But this captures the essence of my definition of commoditized software - something that's been done and from which others have derived a basic understanding of how it was put together. The knowledge of relativity could be categorized as a type of intellectual currency with real value, just as the knowledge of software building blocks also has real value. Yet, no one assumes that someone who understands relativity is another Einstein, and no one assumes that those who understand software building blocks are Kernighan and Ritchie. Basically, I'm talking about the trickle-down effect as applied to knowledge industries, and software development is no exception.

So yes, commodity is probably a bad word, but there needs to be some sort of terminology for "been there, done that" or perhaps "several others are about to be there and do that."

Edit at 4pm PDT, by JM: added paragraphs 3 and 4 to explain in more detail the concept of commoditization

Open Source Macro vs. Micro

John MarkLeave a comment

When I've written about the inevitable march of Open Source, there are a couple of things I've failed to note, or that I just got wrong. One of those is that I conflated the issues of open technology trends with Open Source. While both are trending upwards, they are certainly not the same. The central premise that I've advanced before still holds - that is, the internet has led to unprecedented downward price pressure on software, thanks to a market flooded with software and software developers, with the added bonus that they can all collaborate with each other in "real time." This serves to accelerate the development of software, creating a vast, fast-moving pipeline of new features over a broad swath of software markets. As opposed to traditional software feature pipelines, this one is almost self-correcting in that the users, developers and user-developers are in constant contact with one another, adjusting the pipeline as it moves along. This part is boring. At the risk of patting myself on the back too much, my assertion has been proven correct many times over.

No, where I got it wrong was in equating open technology and the trends in that direction with Open Source, as defined by the OSI. Sure, this downward price pressure makes the current open source ecosystem viable, but that's not nearly the same as saying that trends towards openness will necessarily result in an Open Source end. The truth is, there is a wide range of points on the open spectrum. As it stands, I've written a great deal about "macro" open trends, but not much about what happens on the "micro" level. With this post, I'll kick off an attempt to do that.

One point on the open spectrum represents the ideal of Free Software, governed by an overt moral ethos, whereby all players are expected to share alike as a means of building a better technology world. At another point lies Open Source, as defined by the OSI, which is kinda-sorta governed by the same moral ethos as Free Software, but they don't really like to talk about it much, for fear of chasing away the very companies they're trying to attract. And at many other points on the open spectrum lie all sorts of technologies that are neither Free Software or Open Source - even if they have adopted a licensing scheme endorsed by both.

These other non-Open Source and non-Free Software technologies develop a degree of openness for all sorts of competitive reasons. Witness, for example, how Microsoft is attacking the RIT market or web services. In both cases, they have had to be open in order to stay competitive. While Microsoft may end up using an Open Source license in some cases, they often do not, but they still want some of the benefits of openness without giving up too much control. In these cases, Microsoft clearly wants to grease the skids of adoption and lower barriers to entry. There are also startups that wish to tap into open trends, with some coming under fire for using the term "Open Source" without using an OSI-compliant license. While they shouldn't use the term Open Source without conforming to the Open Source Definition, they should at least define their work in such a way that differentiates them from traditional enterprise software plays.

Trends vs. Personal Experience

It's one thing to say that the overall trends favor more open technology and Open Source, but what about on an individual level? What do these trends say about individual projects and their chances of success? The answer, it turns out, is not much. All the open trends in the world won't save a bad project. At this level, it's really all about emotional attachment, warm fuzzies, dynamics of the project leadership, and any number of other factors that lead to more people gravitating to community X over community Y. It is within this "micro" sphere that factors such as project personality, license choice, degree of openness, and yes, project ethics come into play.

It is at this level that community leaders will have to consider the audience they want to attract. Does your desired audience often seem paranoid and overly cynical? You'll have to work extra hard to woo them, and you'll probably need to start with the GPL or even a BSD license. That's not the final step, however. To truly give them warm fuzzies, you'll have to consider their cultural priorities. Will they naturally gravitate towards organizations like the Electronic Frontier Foundation or the Free Software Foundation? If so, you should probably at least consider some form of relationship with them. Making statements about their pet issues wouldn't hurt either - the OOXML debacle presents a great opportunity, as does the recent controversy over what Open Source means. Opining on the tactics of the RIAA and MPAA might help, as well. Of course, these are only suggestions for a certain audience - the ones with laptop stickers that say "corporate websites suck".

I wish I could calculate how much it's worth for a company or project to engage in this sort of cultural activity, but I really can't. It most likely won't help with the enterprise IT buyer, although it's good to remember that they are people, too. Regardless, it's a good rule of thumb that when you're trying to attract an audience, it's good to know what things they care about the most. As has often been noted, it's not enough to open your code and throw it over the wall. I would add that it's also not good enough to woo the audience with just technology - there has to be some force of personality and a willingness to participate in some cultural issues.