29 November 2010
Coffee Houses and Code Communities (and other Network World blog posts)
I was invited last Summer to blog at Network World and have been a bit remiss in keeping up on the home blog. Here's the list to date. Several ideas I think are very worth capturing with respect to the discussion around open source community, business, and IP management
Of Coffee Houses and Code Communities
We can learn a lot about successful community building from Starbucks
Brian Proffitt has a great article on the difference between communities and crowdsourcing and how companies still often get it wrong with respect to their community building by treating them as a group that will get things done. I came across a good model for this separation of ideas quite by accident and it differentiates between the co-creation of the asset and the co-production of the community.
Makers, Users and Buyers of Open Source Software
Understanding your relationship to a project lets you ask the right questions.
More and more is being written about governance and license compliance and open source. The FUD of lawsuits continues unabated. Simon Phipps has an excellent post on trying to break out of the conversational frame that some use around compliance and governance. I try to frame a participants relationship to a project so they can best understand what they do (and don't) need to care about.
How to Talk to Your Lawyer about Open Source Software
Lawyers know surprisingly more than they think about open source software.
If you’re a developer that wants to use free and open source software then sooner or later you’re going to need to talk to a lawyer. Many developers have a working understanding of software intellectual property, but unfortunately software copyright is a space fraught with exceptions and edges and ambiguities. Karen Copenhaver came up with a great way to explain open source to a lawyer, and I managed to find the recording of it again.
It’s Not That Complicated
Too much is being made of FOSS licensing complexity.
We seem to be seeing a rise again in the discussions surrounding free and open source software licensing complexity, and the fear that open source may infect or taint your software. I'm tired of it. It's just not that complicated to maintain a clean IP environment in software development.
Please Don’t Confuse Standards with Open Source Software
While standards and FOSS may overlap, they can’t be merged into one mega concept
Some people want to merge the idea of free and open source software with standards, and indeed open the discussion into one of “open standards.” This confuses two ideas that are very different once you get beyond the idea they both involve collaboration in a technology community.
Open Source: No one is working for free
To understand the economics of open source, look to the R&D of collaboration.
People continue to wonder how to make money in the free and open source software world. It’s dressed up in discussions of how one makes money when you give away the software for free, or why developers are working for free. It can likewise lead to a management backlash of not contributing to FOSS projects because some think their developers are working on FOSS instead of their own work. I take another run at explaining why the economics is in a business's best interests.
A FOSS project isn’t necessarily a software product
For FOSS the question isn’t just build vs. buy but also borrow versus share.
Confusion often reigns over how to judge free and open source software (FOSS) as people investigate using it in their businesses. Do they use Red Hat Advanced Server? Fedora? CentOS? Should they use the community edition of the Alfresco content management server or buy the product? How does one judge the “software” and whether it’s “right” for one’s business? These are all questions that confront developers and IT managers as they encounter the FOSS world. I try to tease it apart for people so they understand the difference between a product for sale and an open source project.
The Patent Purchase Agreement provides that, upon the terms and subject to the conditions set forth in the Patent Purchase Agreement, Novell will sell to CPTN all of Novell’s right, title and interest in 882 patents (the “Assigned Patents”) for $450 million in cash (the “Patent Sale”).
N.B. I'm presuming "Assigned Patents" in the above quote refer to the 8-K, and not the USPTO terminology below.
Taking a quick look at what the USPTO has to say about patents Novell owns as assignee, we find:
- Patents with Novell as Assignee Name or Novell as Inventor Name: 467
- Patent Applications [published] with Novell as Assignee Name or Novell as Inventor Name: 290
So 757 patents and applications. Even adding Attachmate's patent portfolio (14 plus two applications) doesn't really make a difference. I don't know how many "unpublished" patent applications exist in the mix. I don't know if there are a pile of provisional filings that don't show up in the list. I don't know if there are patents outside of the USPTO that are different (unlikely) or overlap in different jurisdictions (in which case one wonders at the import of them if only ~100 were cross-filed. Even doing a search through the USPTO "Patent Assignment Database (Assignments on the Web)" only brings up 775 patents with Novell's name on them.
So to me (naively) it looks like Microsoft vacuumed up the Novell portfolio because it could. I find it more interesting that US$450M was paid for the portfolio. That's about a half million dollars per patent. That seems like a rather large premium when the average patent is supposedly worth about US$75K to file and maintain over its lifetime. (Investors should be curious.) I'm betting it has more to do with Microsoft having a lot of cash and needing to make the overall deal terms palatable to all the partners. So as Brian Proffitt pointed out, I'm not sure things are any more dire today than they were a week ago.