Joey, Though you are just as likely to get many comments on this as none, I would start by saying you should visit the forums on SourceForge and read through the comments there for the last couple of years. You will find a number of enhancement requests, bug reports and even some fixes that might help you with this exercise.
I know you are the new guy without any history in this area, but for those of us who have invested intellectual capital into this process before (again and again), it's hard to get jazzed about it again. This might keep some folks from responding, but I would also encourage them to chime in now. I'll throw my two cents into answers for your questions below to kick things off. > - Aside from bringing the client up to date with the current version of > OpenSRS, what features or enhancements would you like to see? I think bringing the client current is a great start - but one thing that would go a long way toward helping people become more involved in the project would be documenting the existing code much better and providing working hooks that demonstrated ways to replace or supplement existing forms, integrate with payment gateways, connect with back-end databases for billing, connecting in other products, etc. The hook mechanism is very powerful, but it's left as an exercise for the reader to build hooks from scratch in most cases. Real working examples would be very nice. Coding standards and definitions of where things are and where they go would help. What constants exist and where are they defined, what variables exist, when and how to I access them. These things have started to come out with the existing project, but more work needs to be done here as well. Integration of the email service, and email "management" features would be great. At a minimum, allowing someone to add services (IMAP or more storage) to their existing account should be an option -again with billing integration so that a client can pay with a credit card, debit an existing account, bill an open account, hook to a billing system, whatever. All of us have different payment and billing models - and we need flexibility to support these. Bringing the existing client up to speed needs to be more than simply plugging in the current email and cert clients as well. Full integration into the world that Paul started to build would be really necessary. New modules should be seamlessly available to the end user. The whole "shopping cart" theme that Paul started to dabble into with the latest SF client has been well received by my customers - with some complaints though as well. Completion of the vision that Paul started is also necessary. There are pieces of the puzzle that don't fit well today with the SF client - partly due to loss of focus I'm sure. CA registrations are not supported in the cart, and transfers are dropped out completely - as an example. Renewals are the bastard child as usual. Bulk registration, transfer and renewal options need to be added. Again, this is listed in the SourceForge forums, but having no way to upload a list of domains to either register, transfer or renew is a problem for larger clients. I'm sure I could add many feature requests - as could many others here - but if the client was brought up to this level I would be very pleased. > - Aside from Perl, are there any other languages you would like to see > it implemented in? You'll probably hear many sides here as well, but PHP would be my choice. ASP and Java are more limited in their deployment scope today and would not be my choice of a place to bury resources - though I'm sure there will be proponents for both. > - What level of technical support do you expect? Community support is always best, with an active, sharing community of developers. The problem when we are fragmented or disenchanted is this dies out and you are left on your own. Bugs should be addressed of course, and enhancements need a way of being integrated into the product - following standards for integration, configuration options, etc. It takes a champion to make all this work. > - Would you be willing to donate some time and effort to the > development and maintenance of the client, now that it would be a > genuine open source project? Many of us are already putting time into one or more clients. I'm sure with the right motivation many of us will play. The risk here is getting started down this path - again - and being left out in the cold - again. I've thought about taking the PHP Library and simple starting from scratch with my own client; my own architecture; meeting my own needs. Painful, but I at least know I won't be left out in the cold. Solo development has it's benefits as well as it's risks. Have you ever worked on a genuine open source project? There are not many that are successful without a real champion guiding, pulling, leading, pushing-back and containing the beast. If you just turn 100 Perl, PHP or Java programmers loose on the project and expect them to work in a seamless integrated "group" project, it will simply fail with multiple variants instead of move forward with a purpose. I believe that Tucows will still need to take the development lead as well as steer the project or it will fail. The NIH attitude that all programmers tend to have (it's in our nature to know we can do it better and more elegant than anyone else - cheaper too ...) will cause Tucows to release variants or "just for now" clients to meet specific needs - much as the existing OSRS clients were shipped to "fill a gap" as a quick fix client. Very few people will argue that the existing client code is robust or well thought-out or designed... Tucows needs to be as committed to the architecture as any of us - releasing the first client modules for a new service or new service features as part of the client architecture. If Tucows believes that it's faster to "hack out" a new client - then we have built our house on the wrong foundation. I've been involved in a number of open source projects over the years, and most suffer from patches and enhancements that are not written to any coding standard and as such are nearly as much work to integrate into each subsequent release as they are to add the first time. These projects stagnate, or the bulk of the user community is way out of date all the time - as it's too painful to upgrade or add-in the needed pieces to take advantage of the enhancement. I don't know if the SF code base is the right place to start or not, but looking at the two today, I believe it's a better platform to use as a base. It has problems to be sure, but it is at least a foundation. -t
