Hacker News Reader

> It's github. Of course it is predominantly tools for coders. End user applications have wholly separate paths to the user.

To the user sure, but if they are open source, bazaar-model projects, they still need a route to contributors, and GitHub is as suited for that for end user apps as it is for libraries. So while, yes, it's possible that GitHub is unrepresentative for some other reasons, I don't think that “GitHub is for developers” is a reason to dismiss this kind of statistic.

OTOH, it may well be that apps, even open source, are more likely to be cathedral model (instead of bazaar) than libraries, which might reduce the need for using GitHub or some other public repository.

Yeah, this reminds me of the annual claims regarding what programming languages are the most popular based solely on github repos or stackoverflow questions. The methodology is completely inadequate for producing an answer that can be trusted.

You're right of course. I'm the main author of Apache Curator. While it does have a mirror on Github it's mostly consumed via its Maven Central repo. The Maven Central repo is most likely a better source of open source project usage.

Here's how amazingly wide and diverse our OSS world is: I have never even heard of Maven Central.

Maybe not - but some tool that you use probably gets it artifacts from it. http://search.maven.org - https://www.quora.com/What-is-the-Maven-central-repository

I'm not saying me having never heard of it makes it less relevant, popular, etc. I'm saying OSS has become so widespread that an entire ecosystem, seemingly with thousands of packages, can exist completely out of my awareness, despite me being involved in OSS for a couple of decades and having much broader (though often not deeper) interests than most, due to my work.

In defense of my ignorance, I haven't written a line of Java in years, and I assume this is a predominantly Java ecosystem (due to the "Maven" part of the name).

Yeah that's true. Think of the npm ecosystem, the burgeoning Go ecosystem, etc. All full worlds with their own repos, etc.

Of course it is predominantly tools for coders. End user applications have wholly separate paths to the user

Libraries and tools for coders -- what's particular about these? These are the areas where programmers are also the domain experts! So is it any wonder that these are the projects that succeed?

I guarantee openssh, Firefox, LibreOffice, and probably a hundred other applications, are (orders of magnitude) more popular than the top applications on this list.

Let's look at the success of end-user open source applications. Is there a pattern of success being correlated with prevalence of the domain knowledge in the programmer population? There will be other influences, which will bring in corporate resources and skew the degree of success, but I think this pattern holds there as well.

"So is it any wonder that these are the projects that succeed?"

...on github, a community of programmers.

Honestly though, I don't think that's far off in that even those you mentioned are leveraged as a library (Firefox maybe not, not sure. Chrome can be used headless so guessing there's a possibility for Firefox. Some of the open source internals are used in other projects though). But OpenSSH for sure is used within other software. Okay, maybe libreoffice isn't a case (at least I don't think it is).

At this point, I just love seeing GUI software I leverage also coming with a CLI. I learn what it can do for me with the GUI and then can use the CLI to manage the heavy lifting for me.

We could name hundreds, probably thousands, of OSS applications that are more popular than the laughably obscure #4 and #5 in the list in the article (not laughable in the sense that I mean to devalue their work, just that they are so clearly for an extremely niche user, and that user is a programmer).

I don't really care to argue semantics about what's a library vs. what's an app. Because many libraries have a UI and many apps have an API; that's another discussion, really (though, you've got tens of millions of people using Firefox through the UI daily and maybe a few thousand using it as a library daily...I know where I fall on the "is it an app or a library" continuum).

But, seriously, this article looked at one pile of data generated by a site that is entirely by and for programmers and declared that the entirety of OSS is represented by that data. The more I think about it, the more ridiculous, and maybe even offensive, it seems.

Regarding FF headless mode:- https://bugzilla.mozilla.org/show_bug.cgi?id=1338004

Basically, WIP. For now, if you have NodeJS:-

https://slimerjs.org/

It is kinda headless.

> At this point, I just love seeing GUI software I leverage also coming with a CLI.

I really wonder what is the point of a CLI for, say, Krita or LibreOffice.

GIMP has Script Fu (and a newer Python interface) which has been used for wonderfully time-saving things (e.g. process a thousand images with the same plugins and settings and such, implement your own custom processing tools by combining existing ones, etc.)

I'm sure the same sorts of things can be done with Krita, though I'm not familiar with it.

As for LibreOffice, that seems obvious. An easy/automated way to get data into and out of it for processing in other programs. An automated way to process lots of documents that need to stay in LibreOffice but need the same change performed on them (currency conversion, date format normalization, copyright update, etc.).

It's the same reason you'd want anything to be programmable: Automating away the tedious stuff.

> GIMP has Script Fu (and a newer Python interface) which has been used for wonderfully time-saving things (e.g. process a thousand images with the same plugins and settings and such, implement your own custom processing tools by combining existing ones, etc.)

Begin scriptable and having a CLI are two orthogonal concepts. With Script FU, GIMP itself executes scripts. If gimp had a CLI it means that you could be able to do stuff like "gimp --select-pen 2px solid black --moveTo 0 0 --lineTo 100 100 --lineTo 50 50" for instance (for which I don't see the point of using GIMP to do).

Now you are picking on minor wording choices. You asked for clarification and when it was provided you start beating up the person who responded with meaningful content.

https://www.gimp.org/tutorials/Basic_Batch/

Automated file conversion, e.g odf to pdf, comes to mind.

> Automated file conversion, e.g odf to pdf, comes to mind.

but why would it have to be related to libreoffice at all? couldn't the ODF format be implemented as a library, which then both libreoffice and "odf2pdf" command could be implemented upon ?

Once you have a library for reading ODF, reasoning about its structure, manipulating it and rendering it in various formats, that's just libreoffice without the GUI. When starting fresh it might be a decent idea to make it a library, but I don't think it's worth transitioning to if you started with a more traditional design

you could get the feature from any number of areas, I'm just saying that in a lot of cases, the GUI can act as a "gateway" to understanding the functionality of the application and the CLI can then be used to implement/extend/whatever said functionality for personal use. Handbrake is one that I think implements this well.