LWN readers will certainly be aware that your editor spends a fair amount
of time at development-oriented conferences. In some ways all conferences
are alike, but, still, all that experience was insufficient to prepare your
editor for OSBC, which is a different sort of affair. Neckties,
Blackberries, and Windows laptops are ubiquitous. There are booths for law
firms. People wonder about whether customers should buy their "open
source" software licenses on a one-time or subscription basis.
The wireless network actually works, but power outlets are nowhere to be
found. It's all very strange.
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.
Comments (71 posted)
The
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:
Based on our progress during this feature freeze, we will not
complete the feature freeze until August/September. I think we
need adjust expectations about an 8.3 release date, and decide if
we want to radically change our work process.
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:
- Continue with business as usual and ship a very late release.
Certainly PostgreSQL would not be the first free software project to
take that approach.
- Reopen development so that simpler patches which are not currently in
the queue could be considered.
- Defer all patches which have not been reviewed and ship 8.3.0 with the
code which is in the repository now. Some developers are in favor of
this course, but others see it as unfair to the developers who have
had patches in waiting since well before the 8.3 cycle began.
- Simply shove all the pending code into the repository and hope for the
best. This one seems unlikely: the PostgreSQL hackers have a hard-won
reputation for exceedingly solid code that they will not want to put
at risk just to get a release out more quickly.
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.
Comments (12 posted)
May 17, 2007
This article was contributed by Glyn Moody
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.
Comments (none posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: When routers go bad; new vulnerabilities in clamav, libpng, Apache mod_security and mydns
- Kernel: On-demand readahead; Video4Linux2: basic frame I/O.
- Distributions: The Red Hat Global Desktop; new releases of 64 Studio, CentOS and Pie Box Enterprise Linux
- Development: Boo - a wrist-friendly language for the CLI, Nokia open-sources eds-sync,
new versions of BusyBox, Chandler Server, Silva, eSpeak, jack_mixer, XMMS2,
GNOME, GARNOME, KDE, WIKINDX, wxWidgets, FreeMED, Free Music Instrument Tuner,
LV2 Simple Sine Generator, PHASEX, pyliblo, unoconv, LeafRSS,
libnfnetlink_conntrack, GIT.
- Press: Jonathan Schwartz on media censorship, ars technica on Eben Moglen,
Freenode and OFTC partner, Novell and SAP partner, automotive Linux,
Groklaw on software patents, interviews with Chris DiBona, Troy Unrau
and Tristan Nitot, using 'Q' DVD-Author, reviews of Ardour 2.0, Intel's
PowerTOP utility, geographically distributed software development, LogFS
and WindowMaker.
- Announcements: FSF on Microsoft software patents, Apache Axis2/C, Collanos Workplace,
Funambol v6, Open Group announces milestones, Chaos Communication Camp cfp,
XCon2007 cfp, Firefox Dev Conf, 2007 USENIX, DIMVA 2007.
Next page:
Security>>