[omniORB] omniORB's future (and mine too)

Duncan Grisby duncan@grisby.org
Thu, 25 Apr 2002 13:27:55 +0100


Hi,

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
    issue.

    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
    other people.


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
http://www.grisby.org/CV.html


Thanks for taking the time to read all that.

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --