From: Duncan Grisby <duncan@grisby.org> To: omniorb-list@omniorb.org Subject: [omniORB] omniORB's future (and mine too) Date: 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 --