[OpenLayers-Dev] OpenLayers 2.8 RC2

Bart van den Eijnden (OSGIS) bartvde at osgis.nl
Sun May 17 13:34:31 EDT 2009

Hi Charles,

with open source it's not as simple as saying something does not work, 
and expecting people to fix it for free. Remember, Chris is spending 
lots of his spare time unpaid on OpenLayers, which is already a great thing.

If things don't work, and it seems like you are the only one running 
into it, it probably means not many people are using that feature. So 
you've basically got two choices: fix it up yourself and provide a patch 
with testcases, or hire a developer to do that for you. I understand 
that's kind of hard when you don't have a commercial interest or money 
generated from your website/project, but on the other hand you cannot 
expect people to (endlessly) help you for free.

Best regards,

C E M Harrison wrote:
> Hi Chris,
> I understand where you're coming from, but I'm not sure that you yet see my
> point of view, so I'll explain it first as a user of my webpage might see
> it.
> My site has absolutely no advertising, and so represents a net outgoing on
> my part, both in time and expense.  It has been painstakingly created by me
> for two reasons  -  firstly, to publish my creative work, such as it is, and
> secondly, to pass on knowledge that I have acquired over many years.  As far
> as the latter goes, I intend it as a service.  People visiting my site and
> finding something not working as expected may, if I'm lucky, say: "Well I
> guess it's only for free, so I shouldn't expect it to work!", but I would
> think they're much more likely to say: "What's the point of putting it out
> there if it doesn't work?", and go elsewhere.  In particular, I certainly
> would not expect my site's customers to spend their time trying to find out
> why something on the site doesn't work.
> Similarly, whether intended as such or not, Open Layers has created a
> service concerning the proper functionality of which people will inevitably
> have expectations, expectations which it is not in OL's interest to
> disappoint.  When coming to use Open Layers, I am in the position of a
> customer of Open Layers, and, although I am prepared for some give and take
> because I believe in Open Source software, beyond showing that my own coding
> using Open Layers is not at fault, and beyond trying a few things for a
> quick fix if there is one to be be had, I don't expect to spend significant
> amounts of time trying to find out why something doesn't work.  My question
> to you is the same as a customer of my site's would be: "What's the point of
> putting it out there if it doesn't work?".
> Above all, I certainly don't have expectations that things will actually get
> worse, which, as far as the proper functioning of my site is concerned, they
> appear to have done over the last six months.
> That said, thanks for your work on the scrolling bug, in recognition of
> which, if you examine http://trac.openlayers.org/ticket/2078, you'll find
> that I have produced a more cut down version of the test page  -  all the
> significant remaining code involves just Open Layers.  This is a serious
> problem which I believe also to be a regression, and which therefore should
> be fixed it for 2.8.
> Regards, Charles.
> www.macfh.co.uk
>>     -----Original Message-----
>>     From: Christopher Schmidt [mailto:crschmidt at metacarta.com]
>>     Sent: 15 May 2009 17:47
>>     To: c.e.m.harrison at macfh.co.uk
>>     Cc: dev at openlayers.org
>>     Subject: Re: [OpenLayers-Dev] OpenLayers 2.8 RC2
>>     On Thu, May 14, 2009 at 01:14:11AM +0100, C E M Harrison wrote:
>>     > Chris and group,
>>     >
>>     > Please see below, noting:
>>     >
>>     > 1)	AFAIAA, in every case where I have been asked to
>>     provide a minimised
>>     > version demonstrating a problem, I have done so.
>>     If you want help, minimize it. I guess this isn't as obvious as I had
>>     always assumed it was, so I've written an email (just sent) explaining
>>     both the how and why of this to some extent. If it's more
>>     than 20 lines
>>     of code, there's a good chance I'm not going to look at it
>>     unless I can
>>     understand *why* it has to be more in order to cause the problem.
>>     > 2)	The problems that I have reported are in final
>>     applications because ...
>>     >
>>     > >	We invite you to help us test the 2.8 release candidate!
>>     >
>>     > ... and it doesn't matter how well a piece of code performs
>>     in a limited
>>     > environment, no end user is ever going to see it working,
>>     if it breaks in
>>     > the more stressful environment of a final application.
>>     If the application has more 'stress', then there's likely a
>>     reason why.
>>     Is it because there is CSS involved? Additional HTML? etc.
>>     For example,
>>     with #2054, the problem was specific to the PanZoomBar control and a
>>     Google layer -- but I didn't know that until I spent 25
>>     minutes pulling
>>     out one line of code at a time. To be frank, There should be no
>>     expectation that a developer will neccesarily do this. Some of us are
>>     willing to -- I'm generally the more amenable of our group to
>>     this type
>>     of behavior, I think. Most developers won't bother -- and the
>>     end result
>>     is *you don't get the help you need*, and we all suffer.
>>     > >     Your test cases, included below, and previously used
>>     many times in
>>     > >     comments, are not minimized. There is no way that I
>>     am going to read
>>     > >     through 150kb of code to find a bug.
>>     >
>>     > As above, in every case where I have been asked to provide
>>     a minimised
>>     > version demonstrating the problem, I have done so.
>>     >
>>     > >     I see no such notes on either page
>>     >
>>     > Just click 'Notes'.
>>     >
>>     > >	nor do I even see a map
>>     > >     on either
>>     > >     page.
>>     >
>>     > Just click the Google map button.
>>     Without these direct instructions communicated to me, I have to spend
>>     some fair amount of time looking through your code to determine that
>>     this is the right thing to do. If you just want to state that
>>     there is a
>>     problem: Okay, accepted. There is a problem. (And perhaps it is even
>>     new.) However, if your goal is to get the problem *fixed*, then you'll
>>     need to put in more effort in order to get the help you want.
>>     > >	In the latter case, OpenLayers has never sought to
>>     make printing
>>     > >	easy or efficient. There are other tools that you
>>     should use,
>>     > >	and the differences in browser printing make the
>>     idea of doing
>>     > >	so completely impractical.
>>     >
>>     > I cannot accept such an illogical argument.  Yes, there are too many
>>     > differences in browser printing, just as there too many
>>     differences in
>>     > browsers screen output, but printing is as valid a means of
>>     output as
>>     > screen, and is supported under HTML, CSS, etc.  You can't
>>     say you don't
>>     > support it because of browser differences without implying
>>     that you don't
>>     > support output to screen for the same reason.
>>     The OpenLayers Project, on the whole, is about putting maps into
>>     webpages. We take every effort to make sure that the screen
>>     looks right.
>>     We put no testing, or other effort, into making sure that the
>>     printouts
>>     look right. If you don't appreciate the differences here, I apologize,
>>     but speaking for myself -- and I believe I can speak for the
>>     PSC here as
>>     well -- it will never be the goal of the project to ensure
>>     that printing
>>     is on the same level of quality as our screen output.
>>     > >     If you need something, you are always welcome to
>>     create patches and
>>     > >     attach them to tickets.
>>     >
>>     > I want to spend my limited time on this earth in creating
>>     something useful
>>     > of my own, rather than fixing other people's code.
>>     If that is truly the case, then you should not expect anyone else to
>>     feel any differently in the reverse situation. I can
>>     understand that you
>>     have no desire to fix OpenLayers code. However, if the same
>>     is true of
>>     everyone else working on the project, then no fixes get made.
>>     > I have noted in one of the bug reports in which I have participated
>>     > that I have on occasion looked to provide fixes, but have been
>>     > deterred by the lack of proper encapsulation in existing code which
>>     > good OOP should bring, and in fact with that particular
>>     problem I very
>>     > quickly realised that the quickest way to fix it would probably have
>>     > been to start over with two of the most important classes in the
>>     > heirarchy, and I didn't think the OL community would likely
>>     appreciate
>>     > that.
>>     If this is the most time efficient way for you to fix your problem, I
>>     wish you the best of luck in doing so. Given that you have stated just
>>     above that you have no desire to "fix other people's code", I
>>     can't see
>>     a solution to this that will appease you -- since any change to the
>>     OpenLayers library would clearly involve a lot of work in "other
>>     people's code", which you seem unwilling to participate in.
>>     No developer is going to be forced to work on your problems. If you
>>     can't summon the personal interest to fix them, then it is best to
>>     expect that they will remain broken. Reporting the issues at least has
>>     the chance that someone else might take an interest -- but so
>>     long as no
>>     one does, I would not expect any different behavior in the library
>>     than the behaviors you have encountered so far.
>>     Best Regards,
>>     --
>>     Christopher Schmidt
>>     MetaCarta
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev

Bart van den Eijnden
OSGIS, Open Source GIS
bartvde at osgis.nl

More information about the Dev mailing list