Dave Stubbs wrote: > 1) The OSMF through donations and membership, other random donations etc. > 2) Nobody (not by OSM(F) at any rate), so that means we're limited by > how much time people are willing to provide for free (either companies > or individuals). > > And besides which it was a general statement in response to your > general statement about languages. Any applicability to OSM in > particular is a fairly complex question which is, unsurprisingly, > going to result in compromises.
Many corporate boys always go to battle with the stupid argument you made. Your general statement only points out laziness of developers, doing things in shorter time resulting (usually) in suboptimal solutions. Since we are a group of people that not get paid and therefore need to produce better work in order to use our facilities more optimal it is to defend to always try to improve the work, because the userbase grows and the amount of hardware is limited. >>> Which leaves the important question: does it matter for OSM? >>> (and is a full rewrite the best way of fixing it if it does) >> As long it is slow, and someone is stupid enough to try and fix it, it >> matters :) > > Sure, except that the code, once written, doesn't just sit there. > People have to maintain this stuff. It's not just about, "can it be > written?", it's "can it be written and maintained?". > > So I think a better reply (well, maybe just more complete) is that as > long as it is slow, and someone is stupid enough to try and fix it, > and they can convince the guys who are going to end up responsible for > deploying and maintaining it, it matters. The amount of people here that feel responsible for each others code is very low. If you look at the tools available for processing OSM data it is also easy to see that some are superseded a long time ago and others get bitrot by updated APIs. In my perspective; if everything is unittested and the limitations are known, they don't break if they are untouched. To use another well known sales boy quote: "no one is irreplaceable", there will thus always be someone that is capable of reading the documentation, and changing the code. > Sometimes speed becomes important and it makes sense to replace > certain parts of the system, ie: the GPX importer which has already > been down this path. Exactly, and so can we do with the API/XAPI if we want to :) Stefan _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
