[Proj] A re-rationalized API for PROJ.4

[Howard Butler]

> On Nov 14, 2016, at 3:42 AM, support at mnspoint.com wrote:
> 
> ok,
> 
> 
> 
> ... but NO thanks! .. if it does not add anything new .. for example a new projection .. we do NOT want to have it!! --- it is just some rewriting which forces all users to do some tricks and hours of extra work etc. with their working code without actually adding anything usable.
> 
> Please, do not make such changes that are not required!! -- fix bugs and add some **useful** features ... but do not play with the coding ... since that already works! (We actually PREFER to have it old fashion than anything new and stupid!) --- if you like to make a "clean" Proj.4 for yourself just rename it something else and use it! --- but do not mess with the current version ... we have had enough about those idiots that believe they have some KING ideas how everybody should write programs. And then after next 10 years comes the next one ... and the next one ... and the next one ... all are pushing some strange ideas to play with other programmers and make lot of work that is not at all required! Let it be!!
> 
> 
> 
> Rename it and do what ever you like but stop ***playing*** with the original Proj.4 source code, thanks!
> 

Janne,

You misunderstand the concept of open source software and your company's usage and relationship to it. You are essentially proposing is that we the community only fix bugs that impact your company's usage of Proj.4. As I've stated before, there's nothing that prevents you from using older versions of the software. If your company's software is not robust to changes in Proj.4, it is not the Proj.4 project's fault. It is your company's for not putting enough engineering and testing around your product's (free) use of it.

Some interesting things I've found while researching Gerald and his software for the article [1] I've been working on:

- Proj.4's original code style was evolved from Gerald's work on other programs such as Mapgen and WOLF. He refined his style by applying lessons of the previous system he developed, like any good programmer. 
- There were wildly varying code styles for large C projects evolving in the mid 1980s as evidenced by the evolution of C++ and rise of object oriented programming. Typical GNU-style C hadn't taken hold, and the patterns which we take for granted in many C libraries today, such as opaque object APIs, public vs. private API, and include file management were not widely settled.
- 30+ year old compilers were not very good. Code styles often reflected compiler deficiencies as much as they did explicit design choices.

Please consider Proj.4 in that context. I presume the idiots you're talking about are the fashion-concious, fad-applying programmers, and not Thomas or any of the rest of us contributing and working to improve the manageability, usefulness, and professionalism of the Proj.4 codebase and its website at http://proj4.org. If you've been following any of the thread that Thomas has been writing in github and on the mailing list, you'll know that his improvements are not simply for his edification. It's still C, and the only software fashionability that could ever possibly be achieved is hipster irony.

Here's a list of things the Proj.4 project now has that it did not when Gerald was just tossing tarballs into the ether:

- revision control
- bug listing/tracking
- automated tests
- automated tests that run every time code is committed
- a website that is generated every time code is committed
- releases
- contributors

Each of these things improve the Proj.4 to make your company's (free) use of the software more valuable. None of them would exist if people like Thomas were not committed to keeping Proj.4 viable and alive as an ongoing open source software project. Your company benefits from that, and if you think it doesn't, please internally fork the code and do your own thing. When you do, we will be ahead of you at every iteration.

Howard 


[1] http://lists.maptools.org/pipermail/proj/2016-September/007493.html