SCALE 8x: Proprietary software companies and open source

You wouldn't flame a puppy, would you?

Mark Stone, deputy director of the new Microsoft-backed CodePlex Foundation, showed up at the Southern California Linux Expo (SCALE) with a laptop running Puppy Linux, complete with adorable desktop puppy logo. Stone's presentation, shown in the "Puppy HTML Viewer" application, set a new record for graphic simplicity, even by the standards of this year's SCALE, where any slide format other than the OpenOffice.org Impress default was rare.

While the CodePlex Foundation itself is new in 2009, Stone was at the event to make a familiar pitch: companies that do proprietary and in-house software development still need to be persuaded to act in their own best interests, and need help to decide to participate in open source development when they can derive benefit from it. Stone has been making the same point as an editor for O'Reilly and Associates, where he edited the essay collection Open Sources along with other titles, then later as director of the developer relations program for SourceForge. And, he argues, the point still needs to be made.

The CodePlex Foundation, which Stone called a "broker that can mediate", recently saw its first release of a non-Microsoft project, the MVC Contrib model-view-controller framework for the Microsoft ASP.NET platform. More releases, not all .NET related, are on the way, Stone said.

Any big company is likely to be a user of some open source software, he said, "but when you look at what of their own software they release as open source, some are doing better than others", Stone said.

The situation is better than it was in 1995, when almost all free software development happened off the corporate clock. "The trend is for corporate development and open source to overlap more and more." But, he said, the shift to paid development has been more a matter of open source developers getting paid to do it, and less about proprietary or in-house software developers being able to release their work. Open source developers are getting paid to work for companies, but what about taking corporate development organizations and getting them plugged into open source?

Understanding decision makers' motivations is vital. While most software developers view innovation as a good, often the people who make decisions at companies value predictability and "protecting the brand" over improving the product. "Innovation is risky and scary, and something to be avoided at all costs", he said. What goes into the product is a brand management decision.

Some businesses are friendly to customer innovation, and actively look for how people are misusing the product. Skateboarding started with proto-skaters modifying surfboards and scooters, and today, "extreme" sports vendors bring customer's modifications in-house and base products on them. Others are more conservative.

Knowledge above code?

Stone argues that full-bore participation has value that throwing code over the wall doesn't. "The mere act of releasing some code isn't that much. What we care about is not code sharing but knowledge sharing. The source code by itself doesn't actually transfer that much knowledge", he said. "If you want to understand the software you have to understand its caretakers."

Another difference is that companies intend to put more knowledge into formalized systems. In open source, "we're very comfortable with a tribal approach to knowledge," Stone said. Companies, on the other hand, want knowledge better nailed-down and formalized. "They want you as an individual to be replaceable." Differences may be more aspirational than real. Anyone who has tried to build a proprietary or recently-freed codebase for the first time will understand how much "tribal" knowledge is still there. "There are good practices on both sides", Stone said. The "replaceable" individual is impossible in open development, though. "Reputation travels with you as an open source developer", he said.

The process of how to do open source has gotten much easier, with the rise of easy-to-use project hosting sites such as the original SourceForge, Google Code, and GitHub, and what Stone called, "consolidation around a half-dozen or so key approaches to licensing." The hard part, though, is still the decision of whether or not to do open source in the first place. "For business decision-makers, 'why would we release something as open source?' is a hard question."

A common example of a good case for participating is a company that finds itself carrying a substantial "patch load" of local modifications to open source software. For example, Stone worked on a project that modified MediaWiki to add role-based access control support, not part of the upstream project at the time. Do you just carry the patch load, and reapply your modifications when getting a new upstream version, or attempt to participate in the process by offering changes to upstream, or gathering other users and forking the project? Even thinking about the question is outside some users' vision. "That open source decision is a possibility you need to get business decision-makers to think about."

If your worst problem is differences in development practices, he said, "Congratulations, you're 90% of the way there. Good software development looks very much the same," whether it's open or proprietary. "Don't assume there are differences that aren't really there", he said. In addition, corporate decision makers need to learn to disbelieve myths, such as the myth that open source can't do software testing.

What's missing?

Companies expect a legal entity on the other end of a contractual relationship. For example, Microsoft receives automatically generated crash dumps from software running on its Windows platform. But user data is confidential, and Microsoft won't share customer data without an NDA. Someone needs to enter into one in order to see the crash dumps. There are many existing umbrella organizations, but, Stone said, "We exist because none of them is meeting all the needs." Microsoft itself has done some open source releases but the foundation "will make it easier to participate."

The foundation is not tied to Microsoft hosting infrastructure. The new MVC Contrib project has a project profile on codeplex.com but keeps its source code hosted at GitHUb. (Codeplex.com documentation only lists revision control support for Mercurial, Subversion, and Microsoft Team Foundation Server).

For companies to use the CodePlex Foundation is like "not reinventing the wheel" in software, Stone said. "There are legal processes that you want to re-use and leverage as well." With a substantial staff and million-dollar budget, the new foundation is prepared to be flexible helping companies with the legal paperwork. The Apache Software Foundation has one contributor agreement, and one license, but CodePlex can customize these things. "What do you need in terms of contributor agreement and license?" Stone asked. More news will be coming at next month's Open Source Business Conference in San Francisco, Stone said.

Previous commenters have reacted to the prospect of a wholesale dislocation of the software business with something less than panic. Richard Stallman famously pronounced, "Writing non-free software is not an ethically legitimate activity, so if people who do this run into trouble, that's good! All businesses based on non-free software ought to fail, and the sooner the better." Paul Graham later wrote, "When I say business can learn from open source, I don't mean any specific business can. I mean business can learn about new conditions the same way a gene pool does. I'm not claiming companies can get smarter, just that dumb ones will die." Stone and the CodePlex Foundation are offering an alternative that doesn't involve an office chair auction and a massive dump of perfectly good business cards into the recycling bin.

Index entries for this article
GuestArticles	Marti, Don
Conference	Southern California Linux Expo/2010

---

to post comments