Last Week's Edition carried
an
article on the difficulties of the PostgreSQL business, using Pervasive
Software's exit from that field as an example. Numerous comments were
posted, but none mentioned another PostgreSQL-based business which, by all
appearances, is going strong. That business is
EnterpriseDB, which has
just
announced
the closing of a $20 million funding round.
EnterpriseDB's main offering is a version of PostgreSQL
aimed at companies looking to get away from Oracle. All of the expected
support offerings are there, but the key piece is a compatibility module
which makes it easy to port Oracle-based applications. That greatly
reduces the cost of moving to PostgreSQL, though customers will have to
cope with losing the soft, warm feeling that comes from dealing with Oracle's
contract negotiators. The biggest customer for this offering, so far,
would appear to be Sony, which is moving its online games sites over to
EnterpriseDB.
Unlike PostgreSQL, EnterpriseDB is not free software. It can be freely
downloaded, and the license even allows for free use - as long as the user
has a single-CPU system with less than 1GB of RAM, and the total database
size does not exceed 4GB. Those who want to run larger systems or who
want support from EnterpriseDB can pay between $1000/year (per CPU) for
"Silver" support up to $5000/year for a "Platinum" package with 24x7
support, one-hour email response, tuning assistance, and access to the
source code. See the
EnterpriseDB pricing page for details.
So this company may look like the exception that proves the rule. It is not
really selling PostgreSQL support; instead, it is selling licenses and
support for a proprietary product which happens to have PostgreSQL at its
core. The company does not release its code as free software, and it is
distributing a number of enhancements (including the Oracle compatibility
layer and a number of claimed
performance improvements) without contributing those back to the
PostgreSQL community. From the point of view of the PostgreSQL license,
there is nothing wrong with this behavior; the PostgreSQL developers have
explicitly allowed their work to be used in this manner.
This is not a case of a company hitching a free ride on a free software
project, however. The company's senior database architect is Bruce Momjian, a
long-time top-tier PostgreSQL hacker; a number of other PostgreSQL
developers are on the payroll as well. Much of the work these people do
does go right into the PostgreSQL code base. The company has also contributed to a fund
to sponsor future PostgreSQL development. It would be hard to argue
against the idea that EnterpriseDB is, on the whole, a good thing for
PostgreSQL, even if its proprietary software business model does not sit
well with everybody.
As it turns out, EnterpriseDB
does offer PostgreSQL support - at least, for Sun customers running
PostgreSQL on Solaris. For everybody else, there is a
very long list of support providers out there, most of them apparently
quite small companies. So the PostgreSQL support business might not be
quite as hard as last week's article may have indicated - though it appears
that a proprietary twist may be required for those wanting to go for the
big bucks.
Comments (2 posted)
August 9, 2006
This article was contributed by Stacey Quandt
Google
used the recent O'Reilly
Open Source Convention (OSCON) to announce that it is launching a
project hosting service. The two
primary features of the this service are Subversion hosting,
and a brand new take on managing bug reports.
Google has seven Subversion
developers on staff who are building a new storage back-end for
Subversion to store data in a "Bigtable." A Bigtable is a system for storing
and managing very large amounts of structured data. The system is designed
to manage several petabytes of data distributed across thousands of
machines, with very high update and read request rates coming from
thousands of simultaneous clients. This architecture allows Google to scale
Subversion up to the meet the demands of storage and concurrency it
believes will be needed to serve its members. According to Google's Greg Stein,
“The existing two back-ends for Subversion (Berkeley DB and flat files) just do
not have the capability to scale to our needs. The Bigtable system also
gives us things like failover, monitoring, and performance tuning
capabilities that are not present in the standard Subversion
back-ends.” More information on Google's version of Subversion
can be found on the FAQ.
When asked if Google intends to contribute its Bigtable code back to
Subversion, Greg Stein responds: “We're certainly not opposed to the
concept, but the devil is in the details.” The issue is that the code
that interacts directly with Bigtable cannot be contributed back to the
Subversion project since Google has no plans to publish the source code to
Bigtable at this time. Stein explains, “We have made a number of
changes in the functional tests, and a couple higher level libraries that
we are going to contribute back.” However, source code changes that
are highly specific to Google's environment will not be contributed back to
the Subversion project because as Stein says, “It would not make
sense...[since]... those changes would needlessly pollute the code base
with no measurable benefit for others.” In essence Stein isn't
opposed to contributing source code back to the community and stresses that
“We've got to figure out what the best line is that helps the public
code base".
One potential solution is to publish a non-working copy of the back-end
database simply to see if there is some interest in the open source
community for reviewing Google's model. Stein says: “The lessons
learned and control/data flow patterns might be helpful for
other, future back-ends.” Since Google started work on a version
of Subversion that could be integrated with Google's technology “We
have been heads-down getting the service built and delivered to the
public”, claims Stein. He further states “We have much more
work that we want to do, but it may be time for a breather to review what
we've done and figure out the best options to get some pieces
published.”
Google's ability to contribute the source code for its issue tracker back
to the open source community falls under constraints similar to those it faces
with Subversion. Stein explains, “When you subtract the Bigtable
code, the search technology, and a few of the other
proprietary pieces, then there is actually very little left.”
Stein asserts Google has talked about this right from the start. In the
event that someone should want to replicate Google's issue tracker Stein,
says, “We'd happily consult with that community about what we've
done.
There may be a couple pieces we can provide (under the Apache license).”
As for the architecture of the issue tracker, Google disregarded the idea
of a heavily structured database and replaced it with a free-form system
based on Google's search technology. Issues can be arbitrarily labeled to
note version information, operating system, milestones, priority or other
project specific information. Users can query across all of the
descriptions, comments, and labels to find the relevant issues. Advanced
search allows a user to search just the labels or just the status of an
issue. On top of this new model for storing and querying issues, Google
built an Ajax-based
interface to make it very easy for users to interact with. Issues are
listed in a standard list format but users can perform basic changes to the
user interface including adjusting the columns and sorting.
Google has also made it simpler to submit a bug report. Stein says,
“Today a user is typically faced with a crazy set of drop-downs and
fields covering everything from priority, to software components, to
the target milestones.” Stein asks the logical question: “How
is the user supposed to know any of this? They just wanted to use that
screaming mp3 server, and have no idea whether the affected component is
Foo or Bar.” Google addresses this potential problem by only
requiring the user to specify a summary and description. The user can also
optionally attach files and an optional indication that they want updates as
developers work on the bug report. Project developers can add,
remove, or alter labels, assign owners, change the status to an existing
bug report, and, when they are creating a new issue to be tracked in
Google's issue tracker, they can add these labels as part of creating the
bug report.
Stein claims, “Most open source groups don't require the heavy
structure or workflow that is present in today's issue trackers.”
Still Stein concedes that there are some large groups that do need these features, but they
are typically in the minority. By focusing on the majority's needs, Google's
take on bug reports could turn out to be beneficial for the open source
community.
Google's Project Hosting enters a crowded space with alternative
services from not only Sourceforge.net but also Savannah and Debian's Alioth, among others. This leads to the
question of how easy is it to import a project, or to export it and move it
somewhere else in the future. According to Stein, the answer is “Not
very easy”. This is because at present there is no way to upload or
download a Subversion dump file. Google engineers are working on both of
these efforts. Stein says, “For upload, we'll maybe do something in
combination with a file upload/download feature or rely on the revision of
Subversion 1.4's sync/reply feature when it is released and after we
upgrade the servers.”
Download is a different story. Google plans to make the dump file
available to project owners so they can always access their complete
information. Stein states, “We know how important it is to open
source groups to know that they are not locked into a hosting service.”
Google does not support the data export capability today but it does plan
on allowing for the export of all information. The import and export
functionality is not defined yet and Google plans to investigate using some
simple APIs for this. Stein voices some concern about this approach and
says: "I have a natural wariness with APIs. If you get them wrong then you
can paint yourself into a corner.”
A question on some peoples' minds is: will Google project hosting offer the
same services as Sourceforge? Google project hosting is similar to
Sourceforge in its goal to encourage open source projects and foster
productive open source communities. Aside from architectural considerations,
another difference between the two services is the new Google service will not include Web site
hosting and will initially target smaller projects.
Since Google has no plans to make it easy to
move a project from other hosting sites it appears that Sourceforge.net
does not have to worry about losing its share of current users.
Stein stresses: “Sourceforge is one the major cornerstones of the
open source community, and we have zero interest in damaging that
foundation.” It is clear that, while Stein recognizes that people may
develop tools on their own, especially once the Google project hosting
system has a better import system, but he says, “We have no
plans to be an instigator for that.” If you try to create a project
at Google Code using a name of a Sourceforge project then Google will stop
the process and note the conflict. An email will be be sent to the owner of
the Sourceforge project
requesting approval (or denying the project creation). Google wants
to prevent malicious impersonation or accidental name conflicts and worked
with Sourceforge to get a list of all hosted projects and email addresses
of the owners. Google is also working with other hosting sites such as tigris.org, java.net and Codehaus to avoid naming conflicts.
Google has set initial storage limits at 100 MB for Subversion, and 50
MB for issue attachments. Stein says, “These limits will be more than
enough for for open source projects, but we can individually adjust them
for valid projects.” The limits are designed to prevent spam or
abusive projects from inappropriately using Google's services to host
content which is unrelated to free software projects or not freely
redistributable.
The first step in getting started is creating a Gmail
account, which is required for project owners and members. Owners
have the ability to reconfigure projects, add/remove other
owners and members, and to manage basic metadata about the project. Members
can commit to the repository, and can change metadata on bug
reports. To file a bug report or issue a comment on one, a user only needs
a Google account with a verified email address.
A Google account can be associated with any email address; a
Gmail account is not required for this purpose. A valid email address is
required so that the project members can get in touch with the person
filing the bug report or in the event that further clarification is
required.
Google requires a Gmail account for project owners and members in an attempt
to obtain a higher certainty that they are not bots that could use the project
space for spam or other malicious purposes. Also the fact that all owners
and members use a Gmail account may also help Google in future
integration efforts.
It is clear that Google wants to participate in the free software
development process and provide a viable
alternative to other open source project repositories.
Less clear is whether Google hosting
is merely a goodwill exercise with the open source community or whether its
goal is to be a profit-making venture, either via advertising revenue or by
encouraging more Gmail usage. Regardless, Google's new offering will no
doubt be a useful service to open source developers and a challenge for
other hosting sites to improve the services offered to their users. As we
all know, competition is a good thing.
Comments (21 posted)
The advantages of free software are not always immediately apparent to all
computer users. Many people think that, since they have no interest in or
ability for working with the source, its free availability is of no benefit
to them. LWN readers, instead, tend to understand this issue well, so we try to
resist harping on the point too much. Every now and then, however, the
problems associated with non-free software hit such a level that one can
only sit back and laugh - before writing a snide article on the subject.
Wired News has been carrying the
story of a robotic parking garage in Hoboken, New Jersey. This garage
is apparently an impressive gadget, for those who enjoy this sort of
mechanical technology. It also depends heavily on its operating software;
without that software, the system cannot operate, and any cars which happen
to be inside remain there.
And that is exactly what happened. Robotic Parking Systems, the company
which owns said software, decided that the time had come to raise its
rates. The city disagreed, and talks between the two came to an ugly
point. Once the old contract ran out and Robotic's staff were escorted from the scene,
the garage was no longer operable and hundreds of cars were left imprisoned
inside. Robotic claimed that any attempt to operate the garage constituted
copyright infringement, since the city no longer had a license to run the
required software.
As is described in a
local newspaper article, the situation was eventually resolved, with
the city licensing the software for $5500 per month. There have been
mumblings about how the city would have been better off running open source
software. A quick check shows a relative paucity of viable free robotic
garage projects at the moment, however.
A slightly older story can be found in this
South Florida Business Journal article. It describes the experience of
a Georgia medical practice, which used the "Dr. Notes" package for its
patient records. The friendly Dr. Notes people decided to raise their
support fees by a factor of four, and, when the practice declined to pay,
stopped providing the monthly password required to make the system work.
At that point, all of the clinic's medical records became inaccessible.
Impounded cars may be a major annoyance, but locking doctors out of their
medical records can lead to life-threatening situations. Holding the keys
to those records can give an unethical company a powerful weapon, useful
for extorting price increases from its customers. It is not the sort of
situation any business would want to get into, much less one which is
concerned with health care. Access to a company's critical data should not
depend on another company's continued good will.
Proprietary software will always carry this kind of risk. It is subject to
the whims of the company behind the license agreement - and corporate whims
can be subject to sudden and catastrophic change. One still hears stories
of business leaders worrying about whether they can handle the risks of
moving over to free software. They would be well advised to consider
thoroughly the risks of not moving as well.
Comments (25 posted)
LWN readers who have consulted our Linux Events
Calendar over the last years will have likely noticed that it is one of
the less attractive parts of a site which, in general, is not well known
for its eye candy. It is visually unattractive, difficult to read, and not
entirely easy to navigate through. It is not integrated with the rest of
the LWN site; it is, in fact, based on an ancient version of Zope and must
contain no end of interesting security holes. And, as if that weren't
enough, the calendar has increased its resource use, to the point that it
is the culprit behind most of the LWN site slowdowns experienced over the
last few months.
It is also history. After a couple of weeks of frantic hacking, LWN.net is
happy to announce the new LWN.net Events
Calendar. There are a few advantages over the old system:
- It is somewhat less ugly than its predecessor. Please note that a
few residual rendering issues remain. It looks nice most of the time
in Firefox, looks better in Konqueror, and looks terrible with
Internet Explorer. It seems that your site code hacker's naive idea
of how CSS works does not entirely match IE's naive ideas on that
subject. Our response, of course, is to recommend immediate Firefox
upgrades for all IE users, but we'll try to smooth out the rendering
as well.
- There are a couple of preferences controlling how calendars are
displayed; logged-in users can tweak them in the account area. In particular, the starting day
of the week can be changed, and the calendar can be configured to
always display in the "printable page" format, making it easier to
read in relatively narrow windows.
- LWN readers can now submit events directly into the system. All
events go through an approval phase before being posted, so there is
no point in submitting uninteresting events (like the East Armpit Meds
Fest, the Annual Blog Spammers' Rendezvous, or SCO Forum) to the
calendar. If you have an event you would like to see on the calendar,
and you've checked to be sure it's not already there, please go to the event entry screen and tell us about it.
Planned future enhancements include increasing the number of event types
represented, adding different calendar views, and an iCal export
mechanism. Meanwhile, have a look, and let us know if you have any
improvements to suggest.
Comments (9 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: A report from the Black Hat Briefings; New vulnerabilities in apache, clamav, gnupg, krb5, ...
- Kernel: Movements in the kernel community; The grand unified flow cache; Connecting Linux to hypervisors; Code of uncertain origin.
- Distributions: Fedora's legacy changes; New releases: Ark Linux 2006.1, Freespire 1.0, Fedora Core 6 Test 2, LinuxFromScratch 6.2; New: Dreamlinux, Sectoo Linux, ZeroShell; PCLinuxOS reviewed
- Development: Season of KDE fosters young students - Part Two, implementing TUNES,
Desktop entry specification 1.0,
new versions of Rivendell, MySQL, Samba, Sussen, Mod_python, eSpeak,
swh-plugins, pcal and lcal, GNOME, GARNOME, Libertine Open Fonts,
Polyform Puzzler, StepMania, DANCE, wxWidgets, Thunderbird, Firefox,
SeaMonkey, PHP.
- Press: HP Balks ag GPLv3 patent provision, VMware vs Xen on Linux virtualization patch,Black Hat coverage, Apple and open-source, Ubuntu on the server, reasons to oppose DRM, using Expect, GIMP file format documented, JDBC 4.0 changes.
- Announcements: Debian adopts OpenVZ, GWeather updating locations, Xandros Joins OSDL,
Mozilla partners with RealNetworks, FSF opinion papers on GPLv3,
Amarok artwork contest, Advancement of Free Software nominations,
PyWeek #3 in September, Valgrind awarded, Firefox User Panel survey,
ARES 2007 cfp, Boston Summit 2006, Amarok audio show.
Next page:
Security>>