Offering regional and national programs, CIO (and CSO) events bring together some of the most respected names and thought leaders in information technology and security. Presented by CIOs and other senior level executives, these invitation-only programs offer timely topics and strong networking. Learn More »
Mid-Market CIO Panel: Tips and Techniques for Improving Vendor Relationships
July 15, 4:00 PM - 5:00 PM U.S./Eastern (GMT-4)
We'll highlight relationship priorities and best practices identified in a Council study, and we'll interact with a CIO panel on the approaches they've used to improve strategic vendor partnerships.
Secrets of Successful Vendor Contract Negotiations for the Mid-Market
Sept. 10, 2009, 11:00 AM - 12:00 PM U.S./Eastern (GMT-4)
On this free public Council teleconference, Matthew A. Karlyn, attorney at Foley & Lardner in Boston, will share tips on negotiating tactics and new, creative contract terms to help mid-market CIOs make better deals.
Executive Competencies Assessment Tool
Assess Your Business Leadership Skills with the Council's new benchmarking tool. Rate yourself in change leadership, strategy, customer focus and more.
Learn more about the CIO Executive Council »Apply today for a FREE subscription to CIO Magazine!
January 08, 2009 — CIO —
If 2008 had a buzzword, it was probably "community." More and more companies are looking to tap into communities for contributions to open source projects. But following the open-source trend just because everyone is doing it isn't good enough. To succeed, you need a well-thought-out community plan that details exactly what your organization needs and wants from its community, and how it can achieve those goals. And you need to do so without raising the ire of the free and open-source software (FOSS) community.
The point of insisting on FOSS project metrics isn't to discourage enterprise open-source involvement—quite the opposite. Organizations can plan for success early on by planning to measure contributions up front. This means setting goals from the start, and then designing a roadmap to get you there. Too many organizations begin with poorly-defined or vague goals (such as "build community"), and wind up disappointed with the results. Then they blame the open-source model. In reality, that's a failure of leadership and clear direction-setting.
Companies looking to invest in community contributions should be aware that it takes time to reap returns on the investment. Throwing code over the wall isn't sufficient to get contributions. Developers need to interact with the community to help support their efforts. It usually takes time for outside contributors to learn their way around a project and to become productive.
If the goal is to "outsource" the majority of development to the open source community, forget it. While a healthy community can provide valuable contributions to company-sponsored open source projects, it is not a substitute for an engineering staff. Contributors also expect some voice in the direction of the project itself, and reasonable governance of the project.
If this sounds like a lot of limitations, the flip side is that healthy communities do contribute a great deal to projects, particularly in terms of testing, patches, translations, new features and help in marketing the open source project. Evans Data research about open source developer trends regularly demonstrates that about two thirds of developers who change source code contribute back to the community.
Before your company launches an open-source project, you should decide what kind of community it wants to see flourish and determine the nature of contributions the business desires. Do you want a massive user community, but you aren't too worried about code contributions? Or is it better for you to have a small developer community that dedicates its developers' time to working on the open-source project that most benefits the corporate goals?
Another option is a developer community that uses and extends the technology, such as SugarCRM, which has a healthy contributor community creating extensions to the technology. Contributions come in many flavors and types, and one size doesn't fit all.
Some companies are content with "source open" projects—that is, projects that are available under an open-source license, but with the vast majority of development done by in-house developers. In this case, you can measure your organization's success by adoption alone.
But once you know what you want... how do you learn if you're achieving it?