In any event, I think we would do volunteers a disservice if we placed them in a special class to which we could only provide positive feedback. (Maliciousness is never appropriate, of course.)
"It's a neat language, but no one has used it to make anything that isn't a toy" is a really common mindset for the people who make such decisions.
The only way to change that mindset is for the evangelists to write software and show that yes, it is possible to write For Realsies software in that language. If that happens to be a rewrite of a successful project, fine - it's still a large project, and it'll inspire more development than someone coming out of nowhere with a project.
Fortunately, your top level comment was taken in good faith by one of the contributors, but this won't always happen (and, especially in a space like editors, where everyone uses them and many people have unreasonably strong opinions, so people doing "unconventional" things may have a history of feeling attacked for their hobby) but not phrasing a comment as uncompromising criticism can encourage productive discussion (instead of randoms like me bringing up non-technical things like this whole subthread).
I'm sorry that comment got down modded. In fact, I think/hope I voted it up.
One of the interesting tensions this dialog has surfaced (at least for me) is the relationship between volunteerism and the way outsiders interact with the volunteer community. More than a few people effectively suggested my comment shouldn't have been made. While I do agree with the need to protect contributors from a lot of what they have to put up with, I'm not sure I'd ring fence those communities quite that securely.
Put another way, if my comment really does fall into a class of those that shouldn't have been made, what are the 'rules' for outsiders engaging open source (or other volunteer) communities?
> Fortunately, your top level comment was taken in good faith
Agreed. But after 30 years on the net, it still surprises me how many people just automatically default to whatever the 'bad faith' interpretation might be. We all read what we read in our own context, and this suggests to me that, for many of us, that context is rather angry and upset.
This doesn't even seem unreasonable to me: if every time my project was discussed it was met with scepticism and outright "why are you bothering to do this?", I would get fairly tired and, after the first few times, get fed up with putting in the emotional effort to see the positive nugget buried in the negative phrasing.
Someone taking 5 minutes to write a comment about a project they've just been made aware of is unlikely to have the context to know whether that project regularly gets these sort of comments ("I really meant it as a way to learn more about the project, please, authors, can you politely answer my rudely phrased question/criticism") and so they should be the ones putting in the effort of research and of starting the conversation on a good foot: questions about the points of scepticism (rather than blank statements) are a good start.
It is, a little, but then again it's par for the course for Open Source projects, which are both volunteer AND seeking to engage a larger community.
It's not like its just some people doing what they like and keeping it to themselves or just offering it as-is. Open Source projects that want to become larger communities and attract more developers AND end users, have to accept external opinion and criticism.
- are mainly driven by paid contributors, with some volunteers
- some number of paid contributors with many volunteers
- have only volunteers
And they are open source:
- in order to engage a larger community of end users
- in order to engage a larger community of developers (doing things with people is often more fun, and/or having more people poking at keyboards allows more, say, of an experiment to be accomplished)
- to serve as a portfolio, e.g., for job seeking
- as a political position (some variation of "code should be open")
- out of habit/because there's no reason to not be open source
(Or some combination of the above.)
As far as I know, remacs is driven entirely by volunteers, but I don't know where it fits into the latter category. The original author has written blog post(s) about it, so clearly they want people to know about it, but it isn't obvious to me if they care particularly about people using the result for editing text rather than, say, investigating and showing off the solutions to problems encountered along the way (portfolio) or being able to collaborate on a fun project with people (community of developers).
In any case, I agree with you about projects accepting criticism, but I think the style of criticism needs to take into account the specifics of the project: something like, there should be less "this is a waste of effort"/"I think you should do something else" and more of the pure technical stuff ("algorithm ABC might be more efficient than the XYZ currently used, as ABC is O(n log n)", or something) as one moves further down either list.
Moreover, while some people work on the endless clones of the same thing, the completely different set of contributors is wasting their time cleaning up / fixing bugs / writing documentation for those endless clones.
Examples are: a lot of Linux distros, which are almost the same but not one of them comes even close to MacOSX as a desktop OS. Javascript frameworks which solve the same rendering problem again and again.
On the other side, there is Spacemacs, which tries to provide solid modern IDE-like experience on top of existing Emacs solution, leaving low-level stuff to emacs core team.
In a business setting, you pay people.
In a hobby setting like that, people compensate by having fun.
Either approach is compatible with producing open-source software; I suspect most LOC of open-source projects are written by salaried contributors at large corporations.
Somewhere in the middle. If you consider the work that goes into making a plane, you'll see quite a bit of it happens outside Boeing. To give one example, think of the aluminium that goes into the plane. Boeing doesn't have to mine bauxite, extract the aluminium from the bauxite, transport it to the place where its sold, etc...
A classic example of this ground-up view was this example given by Milton Friedman about the pencil. I don't agree with many of his views, but I think he makes a good point in this video:
https://www.youtube.com/watch?v=R5Gppi-O3a8
EDIT: Turns out the source of this example may have been Leonard Read:
Regarding...
"On the other side Boeing pay them money so they can proceed to mine."
Perhaps you know more about Boeing's business arrangements than me, but I certainly couldn't verify that that's true. From what little I know, it's possible Boeing's aluminium suppliers work exclusively for Boeing, but it's also possible these same aluminium suppliers have multiple customers. The point being, there could be people who work as part of the chain to produce and transport the aluminium who have no idea who will eventually use it.
You could say the same thing about commercial software (and other) development. They just call it competition. In business they claim it is efficient and drives innovation. In open source it's said to be inefficient and a waste of time.
Creating new things is better than sitting on a sofa watching TV or playing video games all day. Furthermore, it often opens the door to possible new, unforeseen use cases, concepts, and success. Open source has a natural evolutionary path. Survival of the fittest, rather than survival of the richest.
Honesty doesn't keep it from being useless stop energy.
>in the process of porting, someone notices a bug and so submits a patch upstream
I find it a little bit controversial.
But it's not: one might very plausibly not care to hack on C emacs, but care to hack on a Rust emacs.
And at the same time, the same person, might be able to spot a bug while porting C code to the Rust emacs, that will also help fix C-emacs.
If remacs didn't exist the hypothetical developer wouldn't be contributing to full Emacs (it never crossed their mind, or it's too intimidating, or whatever other reason), but through their work on remacs, they've also contributed to the original emacs. The point is that the latter contribution would never have happened without remacs.
I mean, if you have a lot of energy to use and give, and you want to clone something huge, clone one the proprietary tools that have no free/open source equivalent yet in your domain or one of the domains where there are the most serious lacks of FOSS; or clone a web app into a real desktop program; or reverse engineer a proper open driver for whatever device you have which request a proprietary OS, a proprietary driver or a manufacturer specific tool; rewrite a library which only exists in Python or C# into a C or C-compatible library so that every language on Earth can wrap it, etc. Don't go cloning something that is already free multiplatform software just for the purpose of cloning.
We have never had so many people writing open-source programs, taking part in open-source projects, and yet it looks like the progress of open-source over proprietary (and its new form: services) is not what it was in the 90's and 2000's, it stalled, and it regresses in some areas. There has to be a problem somewhere.
This strikes me as a very entitled viewpoint. Why should people work on what you want them to work on? They could be watching TV or playing video games in their free time, but if they work on a project you don't think is valuable, it's somehow a problem?
I imagine that this, for the most part, isn't even opportunity cost: the people working on it probably wouldn't be contributing to full Emacs (or the Guile effort) anyway. And this sort of effort seems like it could be an on-boarding experience to improving the original code base, e.g. in the process of porting, someone notices a bug and so submits a patch upstream, or maybe the repeated exposure to a variety of the internal components gives someone enough familiarity with them to contribute if this project peters out.