Why not just differentiate between an "open source company" and an "open source software company" ?

Matt, I wish I had more time to reply, but that'll have to wait until we see each other next week (I hope). I'll just make one correction to your post, and raise one issue:

First, we do release code we build into open source. We release it to a place called PostgreSQL. We contribute patches, we are working on various performance improvements, and lots more. The only stuff we don't release is what we put into the separate product, which we call EnterpriseDB.

Second, the difference between our perspectives has a lot to do with the GPL vs. BSD distinction than most people acknowledge. Allison alluded to this, and it's an issue that doesn't get nearly enough airplay. I'll speak more on this topic in a post in the near future...

Talk soon,

Andy

I always make the distinction between "Free/libre software" and "Open Source". The latter prevents lockins, but has some 'traps' for extracting money.

This is by no means criticism. I think it's a humble expression of opinion/assessment.

Matt,

Last I checked SugarCRM's license was not OSI-approved. So how are they any more Open Source than EnterpriseDB? I'll agree that Alfresco has the high moral ground, but not Sugar.

Is a company worthy of referring to itself as open source or not and thus presenting as an open source vendor at OSCON? First, I think you must differentiate between open source projects and open source companies. And next, everyone would have to agree on what "open source" actually means. And that's not going to happen anytime soon.

These [EnterpriseDB, Greenplum and Pentaho] are three examples of commercial open source companies, and I think they all deserve to be called so. Some of these doubts and questions have also been raised about Ingres and Actuate [BIRT for Eclipse]. I'll leave the decision on those two as an exercise for the reader.

I've said more on this topic, follow the link from my name. It will be interesting to see how this debate goes, though I think we'll be having it for years to come.

Andy,

I see your name mentioned a lot in "Open Source" press releases, but I think you must open up further. Alfresco, for example, has realised the value of the GPL. It is about reciprocity, not just transparency.

Calling companies open source, in light of the open source definition being about *software* rather than judicial persons, makes as much sense as calling companies free to run, modify, or redistribute.

How do I fork the EnterpriseDB company, again? :)

Calling companies open source, in light of the open source definition being about *software* rather than judicial persons, makes as much sense as calling companies free to run, modify, or redistribute.

Linguistic pedants of the world unite! :) You're right, though, English (along with many other languages) allows you to combine words like "open source" and "company" without specifying what the relationship between the concepts is, and leaves it up to the listener to fill in the connection. Which is why there are so many wildly varying arguments around what is and isn't an "open source company". Everyone bases their argument on their interpretation of the connection, when the pure semantics of the phrase are only "X is a company" and "X has something to do with open source".

My own definition of an open source company? The company must actually release code as part of its core business. There must be both open source risk and reward in the code it writes and releases.

That sounds nice on a theoretical level, but you haven't thought through the implications. If the only way to be accepted by the community is by releasing your own open source product, it means that companies who extend and enhance open source software must fork their own independent version of code and release it. Speaking as the architect of a sizable non-corporate open source project, I'd vastly prefer a company to contribute features back to the mainline code and and hire developers to work on the mainline code than fork their own version. Would Novell be a better community member if they forked "Nono", and left the Miguel and the other Mono developers to struggle to fit in what work they can in their spare time? No. And frankly the arrangement would be as unhealthy for Novell as it would be for Mono.

Your definition creates a false distinction that is ultimately harmful to the open source community as a whole. The risk and reward of a business run interactively with an open source development community are equal or greater than a corporate project that releases code under an open source license as an afterthought, and certainly deserves equal recognition.

As long as you place "commercial" on the other end of the spectrum from "open", you are allowing Microsoft PR to frame your market discussion. It's their Shared Source framing after all. "Commercial" and "open source" are orthogonal. Nat's original with respect to OSCON is still relevant.

http://stephesblog.blogs.com/my_weblog/2007/03/debating_open_s.html

Stephe: I never placed commercial and open source on opposite ends of any spectrum - I think you read your own theory into what I wrote, because I neither believe that nor do I believe the two are "orthogonal" (a nice word, but not in the slightest bit applicable here). I don't need Microsoft PR to frame my discussion - I win every day against Microsoft by marrying commercial and open source in the exact same code, for the exact same customers. There is no need to inhibit a customer's full-fledged use of open source in the name of commercial success, at least, we've seen no reason to do so.

As for Allison, I think through the implications on a daily basis, and come up with the same answer: there is absolutely no reason to coddle those who feel constrained to keep one foot back in the proprietary world simply because they lack confidence that they can deliver purchase-worthy value in open source. It's their loss, and their customers' loss, and I don't feel that mislabeling them as open source to assauge their weak-kneed pseudo-source consciences is constructive. Let's call a spade a spade. I don't think there's any need for a meaningless big tent.

Hi Matt:
My apologies for my lack of clarity. Let me try it in different words.

I accept "open source" and "free software" are attributions of a software license -- how the software creator (vendor, academic, or individuals) chooses to share their software.

Those definitions are a given and were anchored early. This is unlike the use of "open systems" in the 80s-90s which the marketing orgs of the world got a hold of before such a definition was anchored.

The "free software" and "open source" definitions are also articulations of software sharing practices that have been ongoing long before the terms were coined. The medium of exchange may have been inefficient by today's Internet-time (magtape), but it did exist, and people shared software with a full recognition (if not today's sophistication) of copyright ownership. That was certainly my experience at DECUS in the 80s, and I would be amazed if SHARE (IBM's equivalent user group) was less sophisticated.

I believe one can absolutely build a commercially viable and successful line-of-business using free and open source software. Whether the whole company revolves around it (Red Hat, MySQL, Alfresco) or simply a division (IBM in three separate large efforts), it is clearly possible and proved.

My mental model that the "commercial" aspect is orthogonal from the "sharing" aspect (and I mean unrelated in any sort of statistical sense), keeps the discussion clear (for me at least). I can talk about a business and its ability to deliver solutions to customers. There many well studied and documented tactics for building a successful software business. Many of these tactics can be well supported and possibly better supported using free and open source software.

That's a company's decision (both strategically and tactically), and is part of its execution. But it's not causal. And may not even support a direct correlation. Which is why I say it's orthogonal.

And I haven't even begun to discuss collaborative development, or software engineering practice. And these too are separate topics.

I unfortunately used "you" inappropriately in my comments in the comment stream here. I should have used "one". I certainly wasn't meaning "you, Matt". I was more reacting to the broader discussion about defining whether or not a company is an "open source company". I hugely applaud the work that the Alfresco team has done launching the Alfresco software under the GPL. (I suspect it required a huge effort on your part, and at reasonable personal risk.)

But regardless of Alfresco (the software) being free software today and open source software before now, the success of Alfresco (the commercial entity) depends more on economic models from Christensen and business tactics from Moore than sharing policies from Stallman.

Microsoft framed the debate as a spectrum with "open source" on one end, and "commercial" software on the other. This was defensive and deliberate. There are many inside Microsoft that even believe it, which is ironic because it prevents them from better executing using free and open source software for their own advantage with customers. I have seen too much of the same sort of debate in the blog posts, articles, and comments on this topic over the past few days.

I think its a mistaken debate that leads no where helpful. It doesn't inform companies trying to best engage with customers using free and open source software. It doesn't help customers trying to understand how to best use, buy, or create/contribute free and open source software of their own.

pax
s.

Allison, why on earth would you have to fork a product in order to extend it? I contribute to several projects that extend other projects without forking it. If you have to fork a project to extend it (in general) I would say you have serious architectural problems on your hands and the thing is not commercial grade anyway -- run for it.

In fact, forking a project to extend or patch it is the last thing a commercial open source company would want! Contributing fixes and extensions (hooks) that allow you to better encapsulate and another project is a much better approach because you compound the value of both products and their communities. As a commercial open source company I would do everything in my power to maintain and grow "The Network" -- never cut or otherwise shrink it -- that is flushing money down the toilet.

Contributing back to someone else's open source project and then using that product as a base for your own non-open source product -- while a smart move, does not make YOUR product open source.

Your product and the value it directly delivers IS open source when IT or most of it is open.

Personally I think mixed models are fishy but I understand that you must do what is best for your customers and your company. Where is EnterpriseDB's community? That's right -- it doesn't exist. Don't say Postgre is their community, that is A: not true and B: not fair. EnterpriseDB is a member of the Postgre community. They don't have their own because there is nothing for a community to form around -- too bad for them.

Don't be afraid to compete on the value you can deliver to your customers through service. The margins are not in the software -- that is an old idea.

It's not true that you don't find sharks where there are dolphins (it's a myth) but in open source I guess it is.

Hmm, I think you are painting the dual licensing thing a bit too glamorous. The fact remains that companies like MySQL AB make their income just like any proprietary company. The bulk comes in from proprietary licenses with some support contracts to go along (and not the other way around). Furthermore dual licensing companies limit the creation of a true development community. They are "stuck" at only providing an end user community. While Dave Gynn reminded me the other day that "community" is not part of the OSI definition, I must add that in practical terms it is the "community" that brings in the main benefits to open source (the main benefit left of open source without community is the ability to do code reviews).

Now proprietary extension business models do not limit the development community the same way. So if you want to judge the ingenuity of the business models of proprietary extension companies, you should focus on how much of their code is open compared to closed or in other words how small a code base they consider differentiating and therefore exclusive.

It seems to me like EnterpriseDB is doing a very good job in that department. Especially since the key piece they keep close is just for people who want to stay in the proprietary world. I claim that the PL/SQL stuff is for the most part doable in "proper" PostgreSQL stored routine syntax. Therefore the differentiator of EnterpriseDB is mainly syntax compatibility with a proprietary product. However in order to be able to offer this compatibility layer their business model depends on getting in the underlying functionality into the PostgreSQL core itself. I think this is a very "respectable" business model from the POV of the community.

As long as you place "commercial" on the other end of the spectrum from "open", you are allowing Microsoft PR to frame your market discussion. It's their Shared Source framing after all. "Commercial" and "open source" are orthogonal. Nat's original with respect to OSCON is still relevant.

http://stephesblog.blogs.com/my_weblog/2007/03/debating_open_s.html

Calling companies open source, in light of the open source definition being about *software* rather than judicial persons, makes as much sense as calling companies free to run, modify, or redistribute.

How do I fork the EnterpriseDB company, again? :)