[FRPythoneers] Fwd: omniORB's future (and mine too)
rob at pangalactic.org
Fri Apr 26 09:30:25 MDT 2002
I thought I'd forward this along to the list. The background here is
that AT&T is closing its research facility in Cambridge, UK. The
researchers at this lab were responsible for producing both VNC and
OmniORB (and releasing both to the public under GPL/LGPL licenses).
From: Duncan Grisby <duncan at grisby.org>
To: omniorb-list at omniorb.org
Subject: [omniORB] omniORB's future (and mine too)
Date: 25 Apr 2002 13:27:55 +0100
Now that I am no longer an AT&T employee, I'm in a better position to
outline my thoughts about omniORB's future development. Apologies for
the length of this email.
First, if you've looked at the main omniORB web page recently, you'll
have seen that omniORB now has a presence on SourceForge. The full CVS
repository is there, but that's pretty much all so far. In the next
few days I'll expand the omniorb.sourceforge.net web page, and get
some more things arranged in the omniORB project area. It remains to
be seen exactly how the split of things between SourceForge and
omniorb.org is arranged.
At the moment, the nightly FTP snapshots of the CVS contents have
stopped, and the CVS repository at cvs.omniorb.org /
cvs.uk.research.att.com is not being synchronised with the CVS
repository at SourceForge. Those things will be sorted out soon, too.
Now, about omniORB's future development. My current plan is for
omniORB development to progress by three means:
1. Code contributions from the community.
In the past, we always discouraged contributions of anything
except bug fixes and ports to new platforms. That was largely to
make sure AT&T kept the copyright to all the code, so we had the
flexibility to relicense it if we wanted to, and to protect AT&T
from copyright claims. Obviously, that reason is no longer an
So, I intend to open up omniORB development to people who wish to
contribute. However, the main reason that omniORB is as robust and
clean as it is is that we have always been very strict about what
features are added, and the quality of the code. I want this to
continue, so I intend to be very strict about who is given
check-in rights to CVS, and what they are allowed to check in. In
particular, I will want diffs to be sent to me for approval before
they are checked in. This model is used by a lot of open source
projects and it seems to work well.
2. Paid-for features.
If I am going to be able to continue to work actively on omniORB
development, rather than just filter other people's contributions,
I'm really going to have to be able to make some money doing
it. The first way that can happen is if you want a specific
feature added to omniORB. I am open to offers of paid contract
work for either small or large features. A small feature could be
something like adding support for another ORBs' non standard
parts; a large feature could range all the way up to an objects by
value implementation, for example.
3. Paid-for sponsorship.
Rather than paying for specific features, companies may choose to
sponsor omniORB's continued development, in return for recognition
of their support, and a greater say in omniORB's direction. At
present, I don't think this can extend as far as complete
commercial support, but obviously being funded would help me spend
time doing support.
If I get enough response to the two paid-for options, I might be
in a position to employ (or sub-contract to) a small number of
So, that's how I see the development of omniORB itself continuing. In
addition to that, I am looking for more general contracting
opportunities. If you are looking for a contractor who knows a lot
about omniORB, CORBA in general, C++, Python, and all those kinds of
things, I'd love to hear from you. You can read my CV / resume at
Thanks for taking the time to read all that.
-- Duncan Grisby --
-- duncan at grisby.org --
-- http://www.grisby.org --
More information about the FRPythoneers