<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hi Jody,<br>
      Thanks for sharing, interesting article.<br>
      <br>
      For a "Discussion" mailing list, there's usually not much
      discussion on it, so here's my contribution:<br>
      <br>
      > 1. A coherent vision requires centralized design<br>
      <br>
      Seems like a tautology. Not to mention there are countless Open
      Source projects that have a coherent vision, even larger ones (a
      lot of Linux distros for example).<br>
      <br>
      > 2. High-level languages need more design than low-level
      languages<br>
      > The core team for open-source language design is usually very
      small ... Higher-level concepts are then delegated to the
      competing developers of libraries, who design independently of
      each other or the core language team.<br>
      <br>
      Maybe, but it can work well for Open Source languages too. Python
      is a prime example - countless libraries in all manner of fields
      created by innumerable developers, most of which follow the "zen
      of Python" and are "Pythonic".<br>
      <br>
      > 4. Hard cases and boring stuff need to get done too<br>
      True. This is one of the big weak areas of Open Source. Linux
      distro management is a prime example of a thankless job that seems
      to have quite a bit of burn-out. Bug fixing and doc writing tend
      to especially suffer from Open Source, though they can be rubbish
      from paid services too.<br>
      <br>
      <br>
      > 5. Crowd-sourced decisions can be bad for you<br>
      As compared to the HIPPO decision making process (the "HIghest
      Paid Person's Opinion")? Is there any actual research showing
      which is better (I'm sure there is somewhere...)? Otherwise this
      is just an unsupported supposition.<br>
      <br>
      > 6. Our developers work for you, not just themselves<br>
      > Figuring out how other people want to use tools and creating
      workflows that are broadly useful is one of those long-tail
      development problems that open source typically leaves to the user
      to solve.<br>
      and<br>
      > 10. Paid software offers an open quid pro quo<br>
      <br>
      QGIS seems to do this very well (as does GeoServer). By contrast,
      I've reported bugs/issues to ESRI on a number of occasions and got
      back all of the following over the years (paraphrased):<br>
      * "That's not what the standard says" (despite everyone else doing
      it the other way).<br>
      * "Yes it's a crash bug, no we're not fixing it"<br>
      * "We can't take your bug report because you're not a paying
      customer".<br>
      <br>
      Paid-for developers don't work for us either, they work for their
      bosses who will almost certainly have different goals to us.<br>
      <br>
      <br>
      > 7. Unified computation requires unified design<br>
      > 8. Unified representation requires unified design<br>
      These seem like a re-hash of 1 and similarly tautological.</p>
    <p>Ironically, a lot of those "unified" packages are usually glueing
      together lots of Open Source parts. FME has 43 PAGES of legal
      terms for all the component licenses -
      <a class="moz-txt-link-freetext" href="https://cdn.safe.com/resources/fme/FMEDesktop_Legal_Notices_2018.0.pdf">https://cdn.safe.com/resources/fme/FMEDesktop_Legal_Notices_2018.0.pdf</a>
      - most of which are for Open Source licensed tools (Apache, BSD,
      MIT, GPL, etc). I can't find the ESRI equivalent, but I'd be
      surprised if it wasn't similar.<br>
    </p>
    <p><br>
    </p>
    <p>> 9. Open source doesn’t bring major tech innovation to market<br>
      Oh? Is Git not a "major tech innovation" that came to market?
      Blockchain more recently (to the extent it's a buzzword that
      everyone is trying to clamber onto despite it only being suited to
      a limited domain scope)? To name two that immediately pop into
      mind.<br>
      <br>
      > 11. It takes steady income to sustain long-term R&D<br>
      An interesting point. There's a huge amount of Open Source
      software that was created as part of some academic project funded
      by public grants. But when the project ends and grant dries up,
      the project is left by the wayside. Sometimes though. the
      worthwhile ones get picked up by the community (i.e. GRASS).<br>
      <br>
      <br>
      > 12. Bad design is expensive <br>
      > Much has been written about how total cost of ownership of
      major commercial software is often lower than free open-source
      software, when you take into account productivity, support costs,
      training costs, etc. <br>
      <br>
      Seems to be Begging The Question.<br>
      It's true there's a huge amount of literature on the subject, but
      the actual TCO depends on the project. Also, do Wolfram's TCO
      equations include the countless hours people have to spend on
      license management.<br>
      <br>
      That said, I agree with the core premise that something that's
      badly designed can waste a lot of a user's time. The poor docs and
      lack of real QA in a lot of Open Source projects are particularly
      a problem that feeds into this.<br>
      <br>
      <br>
      Overall I think most of the arguments are somewhat specious,
      though there are some good points hidden away in there. Open
      Source and Proprietary both have their places, but there's a lot
      more overlap than the article suggests.<br>
      Sure ArcGIS is much slicker than QGIS and has all the great
      integration/uniformity etc that the article talks about, but for
      support, I'll pick QGIS every time. If you *really* want something
      fixed, you can still pay someone to do it (or do it yourself if
      you have the chops); you're not reliant on a corporate monolith's
      "aligned priorities".<br>
      <br>
      Just my 2p.<br>
      <br>
      Cheers,<br>
      Jonathan</p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2019-04-02 19:15, Jody Garnett
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAOhbgAkh=zJgLDdR71Za7bg1qvXYMzuW=d11EEGW2VppA4h5NA@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">Now that open source is a established part of the IT landscape we can start
to see well thought out articles; which are much harder to answer then the
FUD we encountered earlier in the adoption curve.

<a class="moz-txt-link-freetext" href="https://blog.wolfram.com/2019/04/02/why-wolfram-tech-isnt-open-source-a-dozen-reasons/">https://blog.wolfram.com/2019/04/02/why-wolfram-tech-isnt-open-source-a-dozen-reasons/</a>

It is worth thinking through these topics as we still have a lot of
advocacy work to do in our mapping/location industry.

In the specific case of wolfram I love the work and RnD they have done.
Would much rather see symbolic computing (and so on..) have a wider reach
into more fields then be bottled up by one company. Long term I think that
will occur. Short term I like that the open science is taking folks away
from replying on their tools from a “good science is reproducible science”
standpoint.
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Discuss@lists.osgeo.org">Discuss@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/discuss">https://lists.osgeo.org/mailman/listinfo/discuss</a></pre>
    </blockquote>
  </body>
</html>