Red Hat CEO Matthew Szulik started off his talk with an effect-filled video filled with Gandhi quotes and related material, presumably to the end that open source is headed toward an inevitable victory. His talk, once he started talking, was a fairly general presentation on the value of open source software, standards, interoperability, etc. Lots of talk about how young the people pushing open source tend to be. He also dwelt for a while on the "social mission" of open source software, and discussed just how seriously the open source community takes intellectual property issues. LWN readers would likely not find much new there; it was more of a motivational talk for others building businesses in this area.
There was a session, led by Larry Augustin, on "downloads to dollars" - how to start making money once you have people actually downloading your software. Much talk on how to extract information from downloaders which can be used to "open a dialog" with them. When is the proper point to start requiring registration, with a valid email address, to download a software tarball? It was suggested that the source download is really the same thing as the free trial offerings from some proprietary vendors, with the same end: to lead to the "monetization" phase. It can all sound cynical and manipulative to ears more accustomed to gatherings of developers, but this is the sort of thing people building businesses in the open source mode worry about.
There was a lawyer-led session on reciprocity requirements in the GPL. Much worry goes into trying to figure out just when it might be permissible to ship proprietary components with free software. The presenter, Stephen Gillespie, thinks that GPLv3 might make the mixing of proprietary code easier in some situations.
Another session purported to explore "the future of open source," but seemed to be more about the present of open source companies. Much time was spent conducting polls of the audience by having everybody send their responses as cellular text messages to a special number. Eventually time got tight and the moderator came up with the new idea of having people simply raise their hands instead. Lots of talk about how customers should "buy" their open source software licenses. There was also discussion on how to build a community around software releases, though the main concern seemed to be keeping the download rates high.
In general, participants here are concerned with download counts. A large number of downloads is a crucial indicator of a successful open source release; prospective venture capitalists always want to know what the download rate is. Some participants seem to have concluded that there is a lot of useless downloading going on; people just collect software because it's out there for free. But they still want to know how to improve download rates.
The day ended with a keynote by Eben Moglen. It was a long, wandering discussion in classic Moglen style, well worth listening to. The core point, however, was that the way to build prosperity at any level - from nations to small businesses - is to stand up for freedom. At the business level, that includes using copyleft licensing for software. BSD-style licenses, he says, are "a really good license for your competitor to use." Any business which does not want to provide a free lunch for its competitors, however, should use a license which requires others to give back their changes.
In the question period, your editor asked about his statements that Microsoft would, by virtue of distributing Novell's coupons, eventually find itself bound by the terms of GPLv3. He answered that there was much he could not talk about because he signed a non-disclosure agreement to be able to read the terms of the Microsoft-Novell deal. He had expected that agreement to be moot by now, but those terms still have not been made public. Until then, he says, we can look at the terms which have been put into GPLv3 which require the granting of a patent license to all recipients of the software. We can also look at Microsoft's behavior, which includes "throwing coupons out of airplanes" and attacking the GPLv3 patent provisions, and come to our own conclusions.
Responding to another question (about the lack of terms requiring web service providers to give back changes they are running but not distributing to others), Eben had a fairly strong warning for Google. If the company continues to operate in a secretive way and not contribute back the bulk of its changes, there will be growing pressure for a remedy based on licensing terms. It is really up to that one company, he says, to determine where that aspect of the debate goes in the future.
The second (and final) day at OSBC will include a keynote by Marten Mickos, a panel on license enforcement actions, and a panel on the good (or not so good) effects of the Microsoft/Novell deal. Stay tuned for the report.PostgreSQL relational database management system is an important free software project, providing a solid and capable database system. As of this writing, the project's development roadmap states that the code has been in a feature freeze since the beginning of April, with all candidate patches up for review and merging into the source repository. That these patches will be fixed up, if necessary, and everything will come together for a planned 8.3.0 release in July.
PostgreSQL hacker Bruce Momjian recently sounded an alarm about this release:
It seems that the pile of candidate patches is not being reviewed in any sort of timely manner. So they remain candidates and the 8.3.0 release fails to take form. There are, it seems, a few directions the project could take in response to this problem:
As of this writing, the project has not announced any decisions, but the developers have decided not to change the project July release date - yet. Stay tuned and we will eventually see what comes out.
This episode points out, once again, an important aspect of our process: often the limiting factor in a free software project is not the number of developers, but, instead, the number of reviewers who can look over the code those developers create. This shortage is especially acute in projects (like PostgreSQL) which insist on relatively rigorous review processes. But, in any project, the "many eyeballs" factor is important; if the eyeballs are not there, the free software process is not working as well as it should.
Reviewing patches can be unrewarding work. It requires great attention to detail and the energy to look for bugs in code without the corresponding gratification of having actually written that code. Poking holes in other peoples' work is not fun, especially when those people do not react well. Often it can seem like the same mistakes come around again and again, leading reviewers to wonder if anybody is actually listening to them. So reviewers can get a little grumpy at times. The people who can do the best reviews are usually also some of the project's best developers, and, often, they would rather be developing. So code piles up and the review does not happen.
In the long term, the community will need to find ways to encourage more code review if we are serious about the quality of the work we are doing. Better public acknowledgment of reviewers might be a good start; credit is, after all, one of the chief currencies in which we trade. Perhaps we need some better tools to support the review process; along these lines, the recently announced review board project is worthy of some attention. Some projects have considered requiring potential contributors to review some patches before their own contributions can be merged. The right way to encourage more code review will probably differ from one project to the next, but, one way or another, we can certainly find solutions to this problem.
Businesses are increasingly attracted by the freedom and flexibility that open source provides, but many remain put off from making the leap by concerns over interoperability in the absence of any centralized coordination. The free software community recognized this as a growing problem some years back, and set up projects like the Linux Standard Base to ease compatibility issues. But the LSB deals only with interoperability between GNU/Linux and the applications its runs. As more open source enterprise programs have appeared further up the stack, a secondary — and even thornier — problem has emerged that involves interoperability between the many different combinations of applications.
To begin to address this problem, the Open Solutions Alliance (OSA) was launched [PDF] in February by ten companies operating in the field of open source applications: Adaptive Planning, Centric CRM, CollabNet, EnterpriseDB, Hyperic, JasperSoft, OpenBravo, SourceForge.net, SpikeSource and Talend. The Alliance grew out of a meeting in November 2006. "It was a collection of Bay Area open source vendors that wanted to talk about collaborating to build better enterprise class solutions," explains Hyperic's Stacey Schneider. "The conversation quickly turned to being a community issue that was larger than anything we could do as point solutions."
As SpikeSource's Dominic Sartorio, who is also president of the OSA, explains, the basic inspiration was open source itself: "a large number of commercial entities have grown where open source is a development methodology and means of doing business, and they could collaborate through collective effort in similar ways that developers around the world collaborate on building better software." The OSA also hopes to extend the scope of collaboration: "we were also thinking in terms of taking the notion of community to business users, getting together on common requirements," Sartorio says.
Finally, the OSA intends to tackle another problem its members constantly face when bidding for contracts. "Open source just hasn't been one of the alternatives that [a] particular customer may have considered," Sartorio explains. "They may have a short-list of proprietary vendors, but they haven't even thought of the open source one. And we found the reason for that may just be that even if they are are aware that alternatives exist they may not believe it's mature, or they may not have seen enough success stories to believe it's mainstream enough to be ready for them to adopt." The OSA aims to counter that impression by pooling efforts to raise awareness about the maturity and increasing adoption of open source solutions.
One of the main arms of the OSA is its interoperability group, which is headed by Barry Klawans, CTO of JasperSoft. He explained how the group works. "We've actually changed our thinking a little bit since February, when we launched the OSA. Our plan then was we would launch projects on the forums, we have a lot of discussions about them, we drive to some recommendation, codify it, then do a reference implementation. We've since decided that it probably makes sense to launch the initiatives, talk about them a little bit, then dive in and get our hands dirty - really learn by doing. Then, when we've really got some more insight and more detail, put together a formal recommendation, go through that, codify it, and at that point, retrofit any previous work to match the actual codified standard that comes out at the end."
Klawans explains why there was a shift: "It's not like we're a standards organization where people who have been working on this for 20 years get sent to the committees; we're a consortium of vendors who are all trying to work together." According to Klawans, this is an important distinction: "I don't want us to become a traditional standards body, because in my mind that is the opposite end of the spectrum from innovation: when you stop innovating, you then codify."
Sartorio echoes this thought: "Whenever we're driving any kind of interoperability initiative, very, very rarely do we expect that we'll have to invent something new. In most cases we find that there are existing standards, or existing reference implementations, or existing best practices out there, but they may not be widely used, or there may be several different options to choose from and the fact that there's so many options makes it an interoperability problem. So it helps to have an organization like the OSA come in and in a completely open and public way have a debate over what are the right approaches in making an implementation." Klawans emphasizes the importance of outside input, and asks anyone interested to "register at the site, get onto the forums, participate in the discussions, help us out."
As part of its open approach, the OSA has published what it calls its Interoperability Roadmap [PDF], detailing who will do what, and when. For example, the Infrastructure Task Force aims to "reduce install, configuration and deployment burden, minimize the footprint of deployed components, and ensure that disparate applications are easier to integrate out of the box." The Management Task Force, meanwhile, will be addressing ways of improving the user experience of installation, configuration, logging and monitoring by agreeing common approaches.
The first project, to create a common customer view profile, is already underway. As Klawans explains, this has grown into a surprisingly ambitious undertaking. "That just came out of us in the interoperability group talking about well, we want to do this, we want to do that, we want to define the common data model, we're working on security and single sign on," he says. "And at some point, someone said, you know, why don't we build something that shows all of these?" Although audacious, taking such a bold approach for the first project does have its advantages. "It would help us figure out the process," Klawans notes, "it'll really make us sweat the details, and at the end of the day, it will make a great OSA demo."
All this work will be fully open source. "Whenever we're working on any kind of prototype," Sartorio says, "where we want to take several applications and prototype some kind of integration, we're always going to use an OSI license version of any of those products. Similarly, whenever we have to develop new code - for example, if we're taking on an interoperability challenge and there's no existing standard or existing reference implementation - we'll always release that under an OSI license."
This rigor contrasts with a more relaxed attitude when it comes to membership of the OSA, which depends on a company espousing "open solutions" rather than strict open source. As Sartorio explains: "we didn't want to limit ourselves to a very strict definition and then leave out a lot of the hybrid entities out there that really do share a lot of these common problems with us, and really are adopting open source at least as a development methodology, and at least sort of the spirit of doing things in an open and collaborative way."
Given this looser definition, one intriguing possibility is that Microsoft might in theory be eligible to join the OSA. Sartorio comments: "I'm sure if they did, they would be some real interesting conversations. I for one would be concerned about the public image if they joined. I don't think that would happen." Moreover, Sartorio believes that it's "definitely possible" that the definition of "open solution" might be tightened up in the future as more companies adopt OSI-compliant licenses.
It is still very early days for the OSA. New members are joining [PDF] all the time — the initial ten has grown to 18 — and new projects are being defined. But Sartorio already has some clear ideas of what he hopes to achieve. "First, driving the adoption of commercial open source alternatives to proprietary, to the degree that we're going to make every short-list. The second measure of success, on the interoperability front, would be if we've got good solid and ratified interoperability proposals and best practices that cover most if not all of the interoperability issues that one would typically encounter during the course of a deployment or trying to bring different solutions together." To which Klawans adds a third: "another measure of success for the interoperability group will be when closed source vendors start implementing our interoperability rules as well."
Glyn Moody writes about open source at opendotdotdot.
Page editor: Jonathan Corbet
Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds