[OSM-dev] The future of Potlatch

Andy Robinson (blackadder) blackadderajr at googlemail.com
Fri May 2 10:43:50 BST 2008


Tom Hughes wrote:
>Sent: 02 May 2008 9:51 AM
>To: dev at openstreetmap.org; talk at openstreetmap.org
>Subject: Re: [OSM-dev] The future of Potlatch
>
>In message <d0e910d7e2ae90d850f5587d7d5ef282 at systemeD.net>
>        Richard Fairhurst <richard at systemed.net> wrote:
>
>> For most purposes AS3 probably is a better language - except for the
>> fairly major proviso there's no open-source player even in development.
>
>As far as I'm concerned this is quite a key point, although I know
>that Steve disagrees with me violently on this ;-)
>
>In part it's an entirely selfish attitude in as much as that Adobe
>show no signs of wanting to support flash on 64 bit linux which means
>that I am left having to rely on the free players or struggling to
>use the 32 bit flash plugin via a kludgy wrapper that barely works
>at the best of times.

I believe there is the temptation to think that the project should always
pamper to all of us who have grown up with it thus far, afterall, if it
changed significantly from our prior experience or expectations we would
probably feel more and more left and out and ultimately move on to other
things. I hope that doesn't happen for any of us.

However, we can't avoid the observation that the project continues to grow
exponentially and as it does so, and assuming it continues to do so, the
number of potential contributors and users will probably increasingly come
from non opensource backgrounds. More and more will be wanting to experience
OSM from the standard ibm clone box running the big corporate software
offerings. So, we shouldn't leave our heads in the sand, development on all
fronts should be encouraged, open source or proprietary really doesn't
matter, surely the community will decide what it wishes to use.

The one bit I feel strongly should not be tampered with without widespread
community agreement is what happens at the database end, and that includes
what should and should not be available via the API (or any additional API's
that get suggested). If we want to maintain true openness then we make it
clear what the API can and can't do (we already do this), be responsive to
new ideas for opening up the API and provide every assistance to those
developing tools that use the API. Those tools, whether they are editors,
viewers, routing products, mobile phones or whatever, should in my view be
allowed to develop separately from the core OSM function. This means that if
there are 10 editors out there we really shouldn't favour any particular
one, but make all that comply with the requirements of the API available to
users.

Cheers

Andy





More information about the dev mailing list