Hi Vincent ... comments in line. > Hello, > > The example given by Joel is not really relevant to the proposal. Here > Martin is really suggesting some spring cleaning rather than any > rewrite from scratch. > Understood. I think you may be surprised at the level of spring cleaning I propose - even for referencing :-) Or perhaps not; Martin has watched a few developers wander into FactorySPI before ... > In our case, one of the major benefits of open source is to create a > project without business constraints ( "It will be released when it will be > ready") and produce a really good source code quality. This is why Linux and > others major FOSS projects won important battles against closed source > projects. > > Now we are all trying to meet deadlines, we tend to have a "It will > bereleased when my client needs it to be" but I'm sure that in the middle > term projects who don't respect the initial policy will die by the lack of > quality of its source code (remember everybody can have a look at it). If we > continue thinking GT evolution only with business in mind, and if we don't > take care at GT code quality and consistancy of it's architecture it will > never be a serious alternative to ArcObjects or MapObjects or whatever > proprietary geospatial toolkits. > Nice argument; if we are serious we should consider making fixed releases every 6 months. Something we have talked about before. > The reality of the market now is to respect interoperability statements by > following OGC and ISO standards because customers want it (cf. INSPIRE). An > other reallity is to produce the best toolkit ever by adopting a strategy > where we can avoid side effects produced by business constraints. Doing > business with a 2.X branch and creating a 3.x branch with no concessions is > certainly the best way to go. My full time job now is to find customers who > can sponsors the 3.0 approach, accepting a longer delay in their projects, > but with a > stronger and sustainable architecture (with good performances of course). > Go Vincent +1
Now the trick in terms of the project is setting things up so we can all be successful; I think you may find the "module by module" approach to be the best compromise? We can start locking down quality and API (make sure you include communication testing and documentation into your cost) as we find "talented customer" who care about such things. I am worried that a few sections of the library will be be suspectable to the "talented customer" approach. A couple of options: - Use OSGeo as a mechanism to obtained funding; not sure if this is a useful direction but there it is - Recruit We are still going to be stuck with a few things; like Oracle support; where nobody is willing to pay because they believe it should just work. And nobody is willing to volunteer because installing Oracle on your machine is to sentence it to slowdown. > It's perhaps an other business model than the one we have been applying, but > I think it will be good for the long run. > Agreed; we need to think of a few more approches; and ones that apply to the rest of the development community. Cheers, Jody ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
