Stephe's Blog

The Linux Foundation Announces the Open Compliance Program

Wed, 11 Aug 2010 00:57:00 GMT

Companies have been concerned about software license compliance with respect to free and open source software for some time. Part of this is due to simple competitive FUD designed to frighten people away from using FOSS or to sell services and tools around it, and part of this was due to genuine concern with license compliance when lawsuits appear because of violations. The Linux Foundation announced the Open Compliance Program at LinuxCon in Boston today to help companies understand and manage such compliance needs.

The issue isn't really one of FOSS usage. The Internet made collaborative software development and software publication easy. Software from proprietary sources with ambiguous licenses (e.g. MSDN, the Oracle developer network) can enter the software development chain as easily as FOSS. As Jim Zemlin pointed out in his blog announcing the program:

I also want to be very clear: complying with open source licenses is actually easier than complying with proprietary ones. (One reason: there is no money involved.) There are countless software audits of users every year, and settlements often range in the tens of millions for large companies. You may not have heard about those cases since they do not get the attention the very few open source cases do, but make no mistake, complying with proprietary licenses is not easy or cheap.

This new program provides tools, guidance, and training to allow commercial organizations to better track and comply with the software licenses that govern the use of the external software they use in their products. The six components announced today:

Training and Education: Training modules cover the fundamentals of open source licensing and compliance activities. There are also free white papers, articles, and webinars available from noted compliance experts.
Tools: The LF has developed tools to help companies improve their open source compliance due diligence. Initial versions of two of these tools are released as open source projects. The tools include (from the press release):
Self-Assessment Checklist: The LF has developed an extensive checklist of compliance best practices and tasks to support an open source compliance program. Companies can use this checklist as an internal self-administered program. [The checklist will be formally launched in late 2010.]
The SPDX Standard Workgroup: The LF now manages the workgroup for the Software Package Data eXchange specification. When completed, the specification will allow companies to report a standardized bill of materials for their software if it's required by their downstream users. [This is especially important for consumer electronics manufacturers who assemble parts from a variety of suppliers into their shipping products.]
A Compliance Directory and Rapid Alert System: The LF has created a directory of compliance officers at companies using FOSS in their commercial products so communication about licenses and compliance can flow more easily. It’s often difficult for open source projects to identify the correct people at companies using their software to address issues of concern.
Community: The above collection of resources will be driven through the existing FOSSBazaar workgroup as a co-ordination point.

This is an important program and it has broad industry support as of today in the announcement, including support from the CodePlex Foundation. By providing these tools and educational services, the Open Compliance Program complements the CodePlex Foundation mission to increase corporate contribution and participation in the open source world, and we heartily endorse and support it.

More ...

Category: Open source

Category: Software development

Category: Intellectual property

Category: Licensing

Open Core and the Open Source Business Model Debate

Wed, 14 Jul 2010 04:57:00 GMT

The past few weeks have seen a resurgence in the debate over whether or not open core is a valid open source business model or not. There has been a lot of passionate and pragmatic discourse from lots of knowledgeable people (Phipps, Ingo, Mickos, Aker, Aslett, Proffitt, O'Grady).

I believe part of the confusion is between the FOSS projects with their attendant communities, and products in the market that incorporate the project. One doesn't know when the governance discussion stops and the market discussion begins. Community development and governance are interesting edges around which to have the discussion.

There are FOSS projects around which individuals and companies participate as equals (e.g. Linux, Apache). The economics of shared collaborative development are well understood and compelling regardless of the size of the participating organization (all the way down to the individual). Companies still happily include the project in their products and services (e.g. Red Hat, Novell, Google, and Nokia with Linux or IBM with Apache) but no single company defines nor controls the governance structure. The governance and ownership may be as formal as a foundation (e.g. Apache, Linux) or as informal as the project leader (e.g. all the scripting languages).
There are FOSS projects that are owned and controlled by a single company in the marketplace (e.g. MySQL, Alfresco, SugarCRM) and who completely define the project's community governance. I think this is where much confusion reigns.
- Publishing software under a FOSS license provides one set of benefits to a company. N.B. I said publishing software — I haven't yet said what software.
- Developing a community requires an investment providing different benefits.

For a moment, let's talk about business. Customers buy solutions to problems. Typically they're buying time (possibly as expertise), convenience (ability to do something previously undone), security (the removal of risk), or some combination of the three. They will always pay for value. It's a simple economic decision based on how they use/exchange their own time and skills. It doesn't matter whether you're discussing individuals or corporations with staff and budgets. It's why markets form and as Drucker best observed: companies don't exist to make money, but to create markets — money is simply a yardstick for measuring success.

Software isn't what customers are buying. This is the old (but invaluable) observation from Theodore Levitt that "a customer didn't want to buy a 1/4 inch drill, they needed a 1/4 inch hole." Customers buy solutions. As Geoffrey Moore observed, the more complete a solution one appears to be, the more likely one is to succeed. It's the "whole product" idea he espoused. The solution the customer is buying means more to the customer than the "software". (This also explains why some customers are very unimpressed with all the hard work a vendor put into their next release — the new software release didn't solve a new problem or better solve the old one.) If you look at the sum of the costs of the parts a company sells providing a solution to a customer versus the sum of the revenues they receive, as long as they spend less than they earn they're profitable and different industries cluster around different margins.

FOSS projects make great buckets of technology out of which to assemble new solutions. As Christensen observed, disruptive business models come from companies that assemble off-the-shelf parts to satisfy new needs, that then evolve themselves into existing markets with very different margins.

No company, new or otherwise, lasts long if they treat their customers or channel badly or fail to execute on the making-more-than-they-spend equation. Bait-and-switch generally doesn't go down well. Customers complain. In an Internet age complaints have a way of travelling. Indeed there are lots of ways a company can fail in its execution.

So rather than having a discussion about whether open core is or isn't a good open source business model, let's talk about how the company runs it's FOSS community. Remember we're not discussing FOSS projects with external governance. We're discussing companies that (i.) promote FOSS, (ii.) build a community around their own FOSS project, and (iii.) use their own FOSS project as a basis of their product solution they sell to customers.

It's easy to judge if they publish a FOSS project. We have the free software definition and the open source definition. The software license either meets the definition and enables users around the project or not. That's the simple bit.

Let's talk about the FOSS community development. The company needs to invest to reap the benefits a community brings. I wrote at length (with pictures) on the differences between communities engaged with projects and customers engaged with products in early May. The simple idea that applies nicely to open core is that customers have money, community members have time but no money, and the community can't be "converted" in any simple way into customers. Communities are incredibly valuable. Communities bring innovation and real world usage, entrench a technology against competition, create experience and expertise (needed for the whole product), evangelism and advocacy (needed to get the word out), and provide a much needed litmus test for potential customers of your product. But community members must get a solution to their problems in community or there's no reason for them to participate. There are many ways a company can fail to develop a FOSS community:

Some companies don't invest in community at all, taking an "if we publish it, they will come" attitude. They think curious downloads must be "leads" in "community" and try to chase them down. This is a failure to execute. At best it's an old school try-before-you-buy strategy and probably won't be particularly successful. It conflicts with the "we like FOSS" message. Throwing source code over the wall under a FOSS license without build and test harnesses and no binaries doesn't encourage clever programmers to share their ideas. No community forms to fall for a bait-and-switch. There is no community.
If you don't provide a viable solution to your community that meets their needs, they won't participate. That's a failure to execute. It's not because you were practicing "open core", but rather your open core provided no value to attract a community.
If you spend a lot of time "selling" your community, you'll upset them and they will leave. That's a failure to execute. Bait-and-switch will certainly destroy a company's reputation with its customers (i.e. people that paid money), but trying to sell people that don't want to be sold just upsets them. For everyone complaining about "open core" bait-and-switch tactics, I would respectfully ask you to name names of companies that sold you one thing, then provided you something else.
If you dabble in open source, then close the project and essentially leave with the open source contributed work, you are angering the very people you want to get the word out and provide the experience around and entrench your technology. That's a failure to execute. Indeed to escape this perception, some companies have created and evolved external foundations (Eclipse, Mozilla, and the CodePlex Foundation are all variations on this theme) to get away from the perception of a land grab on externally contributed work, opting instead to share asset development in an externally governed organization to everyone's benefit.
Of course one can always upset one's community badly enough that they fork the FOSS project and move on.

None of these failures to execute are because the company used an "open core" business model. These are all failures to understand the community's value versus its needs, how to develop a community, or what customers want and how to sell it to them in the Internet age. In the first case of externally governed FOSS projects described above, every participant is very clear on why they participate to their own selfish economic needs and why the collaboration is greater than the sum of its parts. In the second case, where a company publishes a FOSS project, develops the community and controls the governance, and then sells a product based on the FOSS project, the onus is very much on the company to clarify what's in it for the community and the role of FOSS licensing.

More ...

Tags: economics

Category: Open source

Category: Business

Software Freedom, Open Source Software, and Jane Jacobs

Mon, 12 Jul 2010 17:11:00 GMT

And the band played on ....

The debates rage again. The initial thrust of the discussion started with Simon Phipps blog editorial about his view of the failings of the open core open source business model, following on his call for a renaissance of the Open Source Initiative. The debate broadened with posts from people that have lived in the space (Henrik Ingo and Brian Aker responding to Marten Mickos) and continues with excellent commentary from Matt Aslett (451 Group), Stephen O'Grady (RedMonk), and two editorials from Brian Proffitt.

I want to build on an idea that Brian Proffitt began in his discussion. He tries to get people away from the debate around the social value we call freedom and people's desire to create a spectrum for freedom with "free" at one end and "not free" or "closed" at the other end. This view of the world as freedom spectrum goes back to Microsoft's early Shared Source messaging from 2003 through 2005. This conflation leads to debates of order and purity and line drawing on things that are absolute and whether you're in the club or not, all of which are divisive. Brian instead offers the idea that it's more of a Venn diagram with a set of projects that are "free" and the rest are not, and within the free set there is a gradient as it moves to the middle of the set's circle.

I'm still not happy with that debate because I don't think it addresses the underlying problem of value systems and terminology. Having a debate about software freedom versus open source software (and then debating who is more free or more open) suffers the same problems and tensions as arguing that free speech is better than free markets or that democracy is more important than capitalism. They are different ideas. The ideas themselves are each extremely important in their own domains of debate (politics and commerce). The ideas can be synergistic. I would happily debate if one is a necessary foundation of the other, or whether one particularly enables the other, but I think debating whether one is somehow better than the other or more important than the other is an empty debate. All you do at that point is identify yourself to the other participants by the value system in which you choose to expend your own time and skills. (I made my choice a long time ago and stepped into the commercial sphere. It doesn't mean that I don't care about politics and democracy and don't vote my conscience in elections, but rather that I believe I can best contribute in a commercial sphere.)

The Free Software Foundation has done an extraordinary and valuable job for the past 25 years of defining and evangelizing the idea of software freedom. The FSF treats the software asset as property in terms of collaboration in the Commons. It's a discussion about free speech. The Open Source Initiative has expended a lot of effort over the past dozen years formulating a definition and language for how the market needs to think about open source software focusing on the licenses through which the software is developed and distributed. The OSI treats the software asset as property in terms of the market exchanges that need to be addressed. It's a discussion about free markets. Neither view is more correct than the other. They should be synergistic and Simon's desire to bring a renaissance to the OSI is a good one if they find ways for the two organizations to support each other's goals.

More ...

Category: Open source

Category: Licensing

Category: Business

The CodePlex Foundation and the Free Software Foundation Redux

Wed, 23 Jun 2010 13:10:00 GMT

It was brought to my attention that the FSF has re-posted its CodePlex Foundation commentary from last Fall on the day it was announced that I took the position as technical director at the Foundation. I'm not sure that anything has been added to the new commentary. Re-reading the FSF re-post, I can't but point back to my original response. I will add a couple of clarifications.

Category: Open source

Eclipse 2010 Survey Notes Contribution in Open Source Software Projects Declines

Wed, 23 Jun 2010 12:31:00 GMT

I saw from Dana Blankenhorn's blog post the other day that the Eclipse Foundation has once again published its excellent annual survey of Eclipse usage in the world. This is an annual survey that is always interesting because it shows the rise of many free and open source software projects beyond the Eclipse world and their subsequent competition with each other and the traditional products in the marketplace (e.g. Windows, Oracle). There were 1696 completed surveys this year to last year's 1365, i.e. there were almost 25% more respondents this year.

Dana caught sight of a trend noted by Ian Skerrett in his blog post announcing the survey:

Trend #7. Open source participation seems to be stalled. In the survey, we asked a question about the corporate policies towards open source participation. In 2009 48% claimed they could contribute back to OSS but in 2010 only 35.4% claim they could contribute back. Conversely, 41% in 2010 claimed they use open source software but do not contribute back but in 2009 it was 27.1%. Obviously not a trend any open source community would like to see. I am not sure the reason companies would become less restrictive in their open source policies. Any insight or feedback from the community would be appreciated.

The question as asked in the survey reads differently to me: What best describes your organization's policy towards the use of open source software? (Choose one.) Possible answers were:

Does not allow the use of any open source software (1.4%)
Uses open source software, but does not interact with open source project communities in any way (35.6%)
Uses open source software and contributes back (through bug reports, code, resources) to at least one open source project community to help improve the quality of the projects we consume (30.7%)
Contributes significant development resources (contributors, committers and/or maintainers, project leaders) to at least one open source project community in order to help influence the evolution of the projects we consume (7.7%)
Has a business model that relies on open source software for its success (11.4%)
Individual, not affiliated with an organization (9.2%)
Don't know (4.1%)

There hasn't necessarily been an increase in participants that say they can't contribute, but rather that they don't contribute back. Dana and Ian both ask why this might be the case. Looking to the demographics, there may be a number of reasons.

There's an increase in the percentage of financial services participants over the years (6% to 6.8% to 8.4%). This is a group that has historically been careful in how they contribute and where. The IT crowd is also interesting because using FOSS means that they don't need to figure out how to talk with the accounting department to create a PO for a software trial to solve a problem, but turning it around to the contribution side of the equation, they also don't need to figure out how to find a lawyer to ensure they're giving back in an appropriate manner.

There's an increase in the number of students over the last two reports (8.6% in 2007 down to 8.1% then to 9.8%). This number may be the more interesting set of numbers because the fewer students, the higher the contribution status it seems in the graph (p. 27 in the 2010 report). There are absolutely students that contribute and whose contributions are deeply valued by a number of open source communities, but as a rule, they would be less experience developers and are faced with the learning curves of the project, the technology, and the growth of their own programming skills. This has significance in terms of things that are accepted by the community. They also may simply not know how to contribute as many FOSS repositories do a poor job of delivering the guidance to develop a vibrant community that encourages new developers to join.

All in all, the survey is always a great piece of work and the other trends it finds in it's developer community are always interesting.

More ...

Category: Open source

Category: Software development