Re: JOSM enhancements vs. separate plugin
On Fri, 11 May 2018, Martin Koppenhoefer wrote: BSD ~ 0% Mac ~ 8% Linux ~ 27% Windows ~ 65% Thank you. For comparison, these are numbers for market share and the difference to JOSM (April 2018) [1]: BSD 0% (the same, either they are very niche or they are in the 2,45% unknown and use an OS that effectively protects them from revealing their OS) OSX 13,2% JOSM has 40% less OSX users compared to their supposed market share Linux 1,7% JOSM has 1588% of Linux users ... Win 81,7% JOSM has 20% less Win users these are alternative numbers [2] BSD 0.01 % OSX 8,7% -> -8% Linux 2,3 % -> 1174% Windows 88,6 % -> -27% These numbers had always a systematic bias towards Windows. They are a sales marketshare and not a realistic representation of OS usage. E.g. all my private and nearly all the company computers I bought are counted as Windows systems, but they all operate under Linux. Only for embedded or industrial systems and servers it actually makes sense to buy a system without preinstalled Windows. But even these are probably not counted as Linux systems. So probably JOSM's numbers are simply more realistic. That MacOS numbers are similar is a good indicator for that assumption. Ciao -- http://www.dstoecker.eu/ (PGP key available)
Re: JOSM enhancements vs. separate plugin
2018-05-10 23:38 GMT+02:00 Dirk Stöcker : > Hello, > > interesting, do you also have numbers for the operating systems used by >> Josm users in general (win, linux, osx, other unixes, etc.)? >> > > Yes. > > BSD ~ 0% > Mac ~ 8% > Linux ~ 27% > Windows ~ 65% > Thank you. For comparison, these are numbers for market share and the difference to JOSM (April 2018) [1]: BSD 0% (the same, either they are very niche or they are in the 2,45% unknown and use an OS that effectively protects them from revealing their OS) OSX 13,2% JOSM has 40% less OSX users compared to their supposed market share Linux 1,7% JOSM has 1588% of Linux users ... Win 81,7% JOSM has 20% less Win users these are alternative numbers [2] BSD 0.01 % OSX 8,7% -> -8% Linux 2,3 % -> 1174% Windows 88,6 % -> -27% __ [1] http://gs.statcounter.com/os-market-share/desktop/worldwide [2] https://netmarketshare.com/operating-system-market-share.aspx?options=%7B%22filter%22%3A%7B%22%24and%22%3A%5B%7B%22deviceType%22%3A%7B%22%24in%22%3A%5B%22Desktop%2Flaptop%22%5D%7D%7D%5D%7D%2C%22dateLabel%22%3A%22Trend%22%2C%22attributes%22%3A%22share%22%2C%22group%22%3A%22platform%22%2C%22sort%22%3A%7B%22share%22%3A-1%7D%2C%22id%22%3A%22platformsDesktop%22%2C%22dateInterval%22%3A%22Monthly%22%2C%22dateStart%22%3A%222017-05%22%2C%22dateEnd%22%3A%222018-04%22%2C%22segments%22%3A%22-1000%22%7D
Re: JOSM enhancements vs. separate plugin
Hello, interesting, do you also have numbers for the operating systems used by Josm users in general (win, linux, osx, other unixes, etc.)? Yes. BSD ~ 0% Mac ~ 8% Linux ~ 27% Windows ~ 65% Ciao -- http://www.dstoecker.eu/ (PGP key available)
Re: JOSM enhancements vs. separate plugin
Guys, thanks a lot, I do have the answer. The script is not generic. Have a nice day, jiri On 05/09/2018 02:50 PM, Michael Zangl wrote: > Hi, > > About your concrete example: There are several questions to think of: > > * Is your functionality a generic task? (in your case, this would be > something like "create a convex hull") > > * Is that functionality required by a lot of users? > > * Is your functionality approved by the community? Or will there be > objections? In your case, you should especially mind if your plugin > creates "correct" results and if it can be applied by a unexperienced > user without creating incorrect data. > > * Does it integrate into JOSM in an intuitive way? We try not to add > more buttons to the main menu. A nice example is the reworked download > dialog last year: It added some overpass download features while at the > same time making the UI easier to understand. > > > So if there is a place where this feature could be included that does > not interfere with other functionality (e.g. in a preset, ...) and is > universally usable, it can/should be included in core. In your case, the > script is so special that it may be very useful for other people doing > exactly the task you do, but not for the general audience of JOSM. This > is why a plugin is best in this case. > > > There are several more reasons why we add a functionality to core. They > include: > > * It is a function that allows basic access to the Openstreetmap data. > Like the notes layer: There are probably relatively few people using it > and it would be easy to extract to a plugin, but it is a traditional > feature of the OSM website. > > * It is a function that many other plugins / workflows may depend on. > Like downloading Data using Overpass. > > * It is a feature that is used by JOSM internally and where providing it > for the user just means an other button, but not maintaining more code. > Like the Join overlapping Areas tool. > > * The author of that functionality had core commit access and just was > too lazy to write a plugin for it. One example I did are the color > filters on imagery layers (mainly because they required core > modifications any way and were much easier to integrate that way). > > > Michael > > > On 09.05.2018 07:25, Jiri Hubacek wrote: >> Dear JOSM devs, >> >> I would like to ask question about the JOSM enhancements. Where is the >> line between functionality acceptable upstream and the feature that >> should be in separate plugin? >> >> The concrete example - I wrote some script for automatic creation of >> residential area around the selected buildings. I rewrote it to Java to >> be able to push it upstream but it looked too specific to be included in >> "Tools" menu. So I created the plugin (mapathoner). Are there any >> guidelines for these decisions? >> >> Thanks, >> jiri >> > >
Re: JOSM enhancements vs. separate plugin
sent from a phone > On 9. May 2018, at 11:29, Dirk Stöcker wrote: > > No single plugin has more than 50% user base. Even not the ones automatically > installed with windows installer. interesting, do you also have numbers for the operating systems used by Josm users in general (win, linux, osx, other unixes, etc.)? cheers, Martin
Re: JOSM enhancements vs. separate plugin
Hi, About your concrete example: There are several questions to think of: * Is your functionality a generic task? (in your case, this would be something like "create a convex hull") * Is that functionality required by a lot of users? * Is your functionality approved by the community? Or will there be objections? In your case, you should especially mind if your plugin creates "correct" results and if it can be applied by a unexperienced user without creating incorrect data. * Does it integrate into JOSM in an intuitive way? We try not to add more buttons to the main menu. A nice example is the reworked download dialog last year: It added some overpass download features while at the same time making the UI easier to understand. So if there is a place where this feature could be included that does not interfere with other functionality (e.g. in a preset, ...) and is universally usable, it can/should be included in core. In your case, the script is so special that it may be very useful for other people doing exactly the task you do, but not for the general audience of JOSM. This is why a plugin is best in this case. There are several more reasons why we add a functionality to core. They include: * It is a function that allows basic access to the Openstreetmap data. Like the notes layer: There are probably relatively few people using it and it would be easy to extract to a plugin, but it is a traditional feature of the OSM website. * It is a function that many other plugins / workflows may depend on. Like downloading Data using Overpass. * It is a feature that is used by JOSM internally and where providing it for the user just means an other button, but not maintaining more code. Like the Join overlapping Areas tool. * The author of that functionality had core commit access and just was too lazy to write a plugin for it. One example I did are the color filters on imagery layers (mainly because they required core modifications any way and were much easier to integrate that way). Michael On 09.05.2018 07:25, Jiri Hubacek wrote: Dear JOSM devs, I would like to ask question about the JOSM enhancements. Where is the line between functionality acceptable upstream and the feature that should be in separate plugin? The concrete example - I wrote some script for automatic creation of residential area around the selected buildings. I rewrote it to Java to be able to push it upstream but it looked too specific to be included in "Tools" menu. So I created the plugin (mapathoner). Are there any guidelines for these decisions? Thanks, jiri
Re: JOSM enhancements vs. separate plugin
On Wed, 9 May 2018, Jo wrote: I guess it all depends on availability of time of the core team. What surprises me is that plugins that everybody probably have installed like buidings-tools and utilsplugin2 are not 'adopted' into core. No single plugin has more than 50% user base. Even not the ones automatically installed with windows installer. That probably tells you something about how likely it is that others would be. No. It tells you nothing. As utilsplugin2 is specifically our "not ready or wanted for core" test plugin your comment is even less useful. 2018-05-09 7:25 GMT+02:00 Jiri Hubacek : I would like to ask question about the JOSM enhancements. Where is the line between functionality acceptable upstream and the feature that should be in separate plugin? The concrete example - I wrote some script for automatic creation of residential area around the selected buildings. I rewrote it to Java to be able to push it upstream but it looked too specific to be included in "Tools" menu. So I created the plugin (mapathoner). Are there any guidelines for these decisions? There are guidelines, but they are not easy to explain. It is a personal decision based on a few major questions: - is the function interesting for a large part of the user base - does it fit into the overall concept of the editor - is it mature enough to be in the core - do we want to be responsible for it in the future - does the LICENSE match the core requirements - is there already a similar functionality So chances for generic important mature functions with no similar feature existing are good. For others not. Ciao -- http://www.dstoecker.eu/ (PGP key available)
Re: JOSM enhancements vs. separate plugin
I guess it all depends on availability of time of the core team. What surprises me is that plugins that everybody probably have installed like buidings-tools and utilsplugin2 are not 'adopted' into core. That probably tells you something about how likely it is that others would be. Polyglot 2018-05-09 7:25 GMT+02:00 Jiri Hubacek : > Dear JOSM devs, > > I would like to ask question about the JOSM enhancements. Where is the > line between functionality acceptable upstream and the feature that > should be in separate plugin? > > The concrete example - I wrote some script for automatic creation of > residential area around the selected buildings. I rewrote it to Java to > be able to push it upstream but it looked too specific to be included in > "Tools" menu. So I created the plugin (mapathoner). Are there any > guidelines for these decisions? > > Thanks, > jiri > >
