Re: [Geotools-devel] GeoTools 3: when?

[Jody G. <jod...@gm...>]

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