Appreciation for TRS-80 open source projects?

[Eudimorphodon]

Macintosh boards

Sure. But not much from the 70's uses those nasty miniature surface-mount electrolytic capacitors. And those are also multi-layer boards; a damaged trace is a much bigger deal when you can't see it.

 

[LambdaMikel]

Macintosh boards (Macintosh II in my particular experience) succumb to battery and leaky cap damage that had rendered MANY, MANY of them un-repearable.

Right they can be terrible indeed. Amiga 500 I also had some very bad damage to the traces from battery, but was still able to bodge wire them.

 

[cjs]

Who is ranting? The OP just asked a question.

The guy saying this:

Ill just chock this up to the thread i already started a couple of years ago. The Gist being "I dont F#$king get Github".

Just throwing my hat into the mix. One thing I have noticed is how there are duplicate projects of esentially the same thing on Github.. And they are not forks or connected in anyway. Github is a mess.

(And no, LambdaMikel, I do not think you are ranting at all. Your queries are on point and reasonable, and have opened up an interesting—and I think fruitful—area of discussion. Except for the part where the GitHub haters come in and rant, which is right up there with Apple II fanboys ranting about the TRS-80.)

 

[cjs]

Thanks all for the discussion. Correct, I don't intend to rant about anything - these are just my humble opinions and it is not meant as confrontation or something you should feel a need to comment on, so please don't get angry with me

Just in case it wasn't clear, no, I don't consider anything you've said to be a rant in any way. "Why do things get stars on GitHub—or not—is an interesting question, even if not a particularly important one.

IMHO, GitHub stars do matter - not everybody is retired, and having projects on GitHub with many stars DOES make a difference for job hunting....

As a professional software developer for more than 25 years (and having been working on fairly sophisticated software, such as operating systems, even before that), I disagree. I've had plenty of employers look at my work on GitHub, but nobody ever expressed any interest in how many stars anything had. There are just too many other factors going on there, and a certain amount of randomness in terms of whether you "got lucky" with the need for, popularity of or timing of a particular item, rather than the knowledge required for or difficulty of a particular item.

You see a parallel there with reputation on StackOverflow. My highest scoring answer there (367) is to "What does the exclamation mark mean in a Haskell declaration?" which is fairly trivial to any experienced Haskell programmer, and my next highest (151) is for the completely trivial "How do you remove a Cookie in a Java Servlet?" where I simply quote a couple of lines from the API documentation. (I wrote that long after I'd stopped programming in Java; I just happened to be there just after it was posted, quickly looked it up and typed it in, and bingo! 1500 reputation.)

An even more trivial answer, to "How do I delete a Git branch locally and remotely?" has 3755 votes. And, of course, a dozen answers to to "What's your favorite 'programmer' cartoon?", score in the 300-1500 range.

Compare with an answer of mine to "Change pytest rootdir," which embodies some pretty deep knowledge of pytest (requiring reading through the source code as it wasn't thoroughly documented) which has only 23 upvotes.

All this should help make clear that votes from the programmer community are often nothing to do with the skill required to construct the object voted upon, and you should never interpret them as indicating that.

GitHub stars are the only currency and reward that developers get in return for their efforts of sharing their hard work with the community, for free. We want to make sure that it stays like that - so reward them if you can.

As a developer with a lot of code published on GitHub (both in my own projects and in others where I've submitted PRs), no, the stars are absolutely not the only currency and reward we get. In fact, for many of us it's not a reward at all: I have pretty much ignored stars until this discussion, and when I look at them now it's only for the purposes of this discussion. I had no idea how many stars any of the projects you mention had, and no idea how many stars any of my own projects had until this discussion prompted me to have a look at a couple. (And I still don't care.)

Frequently, others than the original developers benefit from their hard work.

Well, yes; that's the point of publishing open source code.

IMHO, everybody that gets a copy of such a device from a manufacturer / shop / reseller should also consider leaving a star on GitHub if the device is found to be useful. It's the least we can do for the original developers.

I think this is a bad idea. Having a good, short username on GitHub is a valuable thing, and having piles and piles of consumers using up that namespace simply to put a silly star on a project doesn't help any new developer looking for a good, memorable name. And I'd far rather have an end user spend his time writing a post on an appropriate forum saying, "Hey, I bought this thing and it's great" than signing up to GitHub and adding a star, since the former is far more likely to convince others to buy the thing. I see no evidence that someone shopping for a retro-thing is using GitHub stars as evidence of anything at all (and they should not be).

I know that making a PCB replica can be as easy as making a scan and tracing the connections (done it myself with a keyboard membrane).

It can be that easy with trivial things like a keyboard PCB, where there's basically nothing to it but the PCB and a bunch of switches. But that's akin to saying it's easy to replicate a car because you managed to easily replicate a child's tricycle.

In case of the Model 1, the schematics are available - sure, there might be some bugs in the schematics, but you always have the original available and can easily recover from any inaccuracies in the specs simply by looking at the working original.

Lol, no. Just no. Go do a replica PCB and you'll find out just how wrong you are.

In contrast, developers of new hardware, original designs, don't have an original... it doesn't exist.

Right. That is in part what can make it significantly easier, depending on the design. You're not constrained to figure out how something was done (often with parts much more primitive than those currently available to you) and then match it; you can simply use modern parts that let you do things much more easily.

This is the reason you see so many modern boards with RAM using static RAM; you can buy large, fast static RAM devices quite cheaply nowadays, whereas contemporary designers were forced, for cost and size reasons, to use dynamic RAM and deal with the hugely more difficult design problems that presented. Modern, fast microcontrollers are another item we now frequently use to save ourselves a lot of time and effort that that simply weren't available to designers back in the day.

And the FreHDv1 project does exactly this sort of thing. Rather than a mess of discrete logic, it uses a GAL and a PIC microcontroller. It handles all the FAT and MicroSD card access using existing open source software.

This is not meant to turn into a flame war - as I said, I appreciate ALL open source projects for the TRS-80, and frequently leave stars even for projects that I don't use (like the Model 1 replica board). And I encourage you to do the same.

I would suggest you not worry about it. As someone who posts open-source retrocomputing and other stuff to GitHub myself, I couldn't care less about the stars, and I suspect most people care almost as little as I do. I'd far rather see my work discussed in forums by people using it than have someone post a silly little star.

That's such an interesting statement... as if designing the IO interface would have anything to do with the complexity of operation that the peripheral performs (also, it needs drivers and what have you!) It's like saying making a car is easy cause you only need to get the steering wheel right.... anyhow. Just my 2 cents.

The I/O interface to which one must work has a huge amount of effect on the complexity of the peripheral, and having a simple I/O interface makes life a lot easier. You're right that, once you get past that interface, there's a completely separate set of complexity related to what the peripheral itself does, but there are also a lot of options for dealing with that in the modern age, some of which (such as fast microcontrollers and the ability to do in software now what one used to have to do in hardware) make life enormously easier when implementing that functionality. What looks complex to the user may actually be quite easy for the designer, and vice versa.

 

[cjs]

Ah, I found the particular StackOverflow example I was looking for that gives a very clear insight into the problems with assigning value to voting of any sort on public sites.

My rep on SO is 26,430, as of this writing. User siride has 205,135. Clearly he's a much better programmer or much more knowledgeable than me or something along those lines, right? Maybe about ten times better?

Well, no. He happened to be in the right place at the right time to answer a really easy question: "How can I rename a local Git branch?" That earned him 18,956 upvotes (and 11 downvotes, for some weird reason) and thus probably over 180,000 reputation. By reputation excluding that answer, we're at about the same level.

Even the guy who asked the question has over 125,000 reputation, five times mine, almost all of which is probably from the 11,627 upvotes he got for that question. Yet he's certainly not anywhere near my level, based on a look at his answers.

Potential employers looking at vote counts (be they on SO, or GitHub stars, or whatever) is immediately a red flag for me.

 

[VERAULT]

I mean if anyone is ranting here.... Its not us. Are you trying to start an argument @cjs ? It sure seems like it.

Anyway I'm not interested.

 

[VERAULT]

Sure. But not much from the 70's uses those nasty miniature surface-mount electrolytic capacitors. And those are also multi-layer boards; a damaged trace is a much bigger deal when you can't see it.

Of course. Macs arent made well. Pretty badly in fact.

I'd say MOST boards from the 70's on the other hand are much easier to repair than boards made in the following decades. But things happen and there are some boards damaged to the point of non repairable.

 

[VERAULT]

Right they can be terrible indeed. Amiga 500 I also had some very bad damage to the traces from battery, but was still able to bodge wire them.

TERRIBLE IS AN UNDERSTATEMENT!

Thats how I got my amiga 500. Battery Bombed from another VCFED member. I was able to repair it thankfully But yes those trap door battery/RAM cards have done in alot of A500 systems The other Amiga line suffer from battery problems as well. Heck, so many vintage computers do.

 

[LambdaMikel]

Potential employers looking at vote counts (be they on SO, or GitHub stars, or whatever) is immediately a red flag for me.

Well it's nice to be in such a comfortable and secure position in your career that GitHub repos don't matter and that you have the choice to flag these companies, rather than the other way around, good for you

I think you are right - but it also largely depends on where you apply "as a professional software developer". I mean, if you strive for MANG (FANG), then all what matters is that you have extremely high frustration tolerance (4 rejections, 5 rejections? come on, you STILL would want to come back AND TRY AGAIN, it's such a great place to work, after all, the gym and the free food are GREAT - only with MANG your life will be complete!), and are willing to jump through all the hoops that HR wants you to jump through, as many times and at whatever time they like. Introductory freshman college coding question (how to sort a list with your hands tight to your back ) presented to you in an arrogant and dismissive manner from kids fresh out of college, who think they know it all (after all, they are the elite, they work at a MANG company!), and neither your PhD nor 40 years of experience matter, really.

On the flip side, I think there are many smaller companies (probably offering more important and more interesting work than selling ads) where it actually matters that you are a doer, self-starter, and that you have some verifable achievements (projects with stars, papers, patents, certificates, degrees, .. tangible and verifiable achievements!) other than being a good coding interview monkey.

Just my two cents - sorry, now I am ranting - no offense

I don't really contribute to SO or Reddit or Quora, so I wouldn't have thought that this is a serious performance indicator or achievement, but I may be wrong. No offense. GitHub repos, on the other hand, are of an entirely different quality, and I maintain my GitHub pages as well as some other profiles on high-impact sites (such as Hackaday), but that's about it.

Thanks for the interesting discussion, I am enjoying it!

 

[cjs]

Well it's nice to be in such a comfortable and secure position in your career that GitHub repos don't matter, good for you

Wow, you've not really read (or at least not understood) a word I've said, have you?

I am not in such a comfortable place or secure position, and regardless my GitHub repos do matter to me, quite a lot, especially as they appear to employers, which is one reason why I spend a lot of time on them and point potential employers at several of them so that they can see how much care I take in coding.

Stars have absolutely nothing to do with that. Tox, for example, has 3.5k stars, and it's a great utility, but an absolutely horrible piece of code, and I'd definitely not want someone who writes code like that working for me.

What seems to have happened here is that you have no idea about how to evaluate a developer's ability to design and write code, so you've decided you'll just look at stars instead. That's not uncommon, but that's not the kind of person or company I'd like to work for, because it doesn't matter to them how good a developer I am: it matters how many stars I can gather. And I want a job building great products, not a job convincing random people on the Internet to "thumbs up" my stuff.

On the flip side, I think there are many smaller companies (probably offering more important and more interesting work than selling ads) where it actually matters that you are a doer, self-starter, and that you have some verifable achievements (projects with stars, papers, patens, degrees, .. tangible and verifiable achievments!) other than being a good coding interview monkey.

You're right that I prefer smaller companies, doing more important and interesting work, where they care about verifiable achievements. But they have to be the right verifiable achievements, and stars on GitHub are not one of them. Stars are a thing used by people who don't understand what good code is, because, hey, it's something they can count and they need no more knowledge than what numbers are bigger than what other numbers.

I don't really contribute to SO or Reddit or Quora, so I wouldn't have thought that this is a serious performance indicator or achievement....

Well, there you go. For you, it's about what you know and not what the guy who's answered hundreds of technical questions knows.

And, as for the stars on the two repos you originally pointed out, I've had a closer look at them and to me it's obvious why TRS-80-Model-I-G-E1 has more stars, and should have more stars, than FreHDv1. Comparing the two, the former has a lot that the latter does not:

1. A much better README. For a start, it's easier to read and better formatted because it's a Markdown file, rather than just plain text, taking advantage of GitHub's ability to render that. And it starts with a picture of the device, which is incredibly useful for hardware designs as it instantly gives an high-level view of how it's going to integrate with whatever it's supposed to connect to. It's divided into sections with headings so you can more easily scan through it.
2. It gives you details and direct, clickable links to some of the more important documents.
3. It uses KiCad and, importantly, tells you what version they used. FreHD uses Protel99, discontinued more than six years ago, and who knows if you can even get a copy any more. Presumably these can be loaded into some version of Altium designer, but there are no notes on how to deal with that, especially if you're not wanting to shell out for a licence just to look at the schematics.
4. They give you rendered versions of the schematic and board for easy reference without having to download the source files and load them up into your CAD program. They also have useful special-purpose renders such as the labels SVG.
5. They give you a bill of materials. With FreHD you have to go through the hardware design and build this yourself.
6. They give you the exact Gerbers needed for a couple of popular PCB manufacturers, so you don't need to generate these yourself. And they gave you additional ordering instructions for information that a PCB manufacturer will require that isn't in the Gerber files because the Gerber spec doesn't cover such things.
7. They give you a full set of assembly instructions, both in the README and as a separate printable document.
8. They give you a "Curiosities" document with design notes and explanations of a few things people are likely to wonder about if they look more closely at the project.

That's just on the hardware side, of course, because TRS-80-Model-I-G-E1 doesn't include any software components. But FreHD does, and looking at this, things just get worse:

1. The directories don't match up with what the README says they are.
2. Some of them are utterly mysterious, such as sw/z80/4p/.
3. Presumably the pi directory in the documentation has been replaced by the trs_hard and trs_hard_m2/ directories, but who knows? What do those names mean? And they have similar contents, so why are there two of them?
4. There's no indication of how to build the system's firmware beyond a note in the README saying, "To build the PIC software, you will need Microchip C18 compiler (free) and MPLab (I used version 8.36). You will also need perl..." Great, but what do I do with those? Clearly I can't just run the Makefile in either of those directories, because those Makefiles don't compile anything; they just build a tarball. (A tarball of what? Who knows. Perhaps a source release? But why would something on GitHub need a separate source release?)
5. The z80 code, or some of it anyway, seems as if it might include pre-built versions of the files. That would certainly be handy for builders of this system, but there's no mention of this anywhere.

If you want to see how important (or not) a lot of this stuff is, I suggest you go clone that FreHD repo, print out PDFs of the schematics and board layers, generate a set of Gerbers suitable for JLCPCB or PCBWay, build all the software, and figure out how you'd program the firmware on to the board. If you even manage to do all this, you'll find that it's a ton of work, much of which could have been saved you had the designer of this project designed it to be replicated by other people, rather than just built by himself.

So, no way that one gets a star from me.

 

[LambdaMikel]

I think you are obsessing over the wrong aspects. But everybody is entitled to an opinion! I appreciate your opinion.

 

[cjs]

I think you are obsessing over the wrong aspects. But everybody is entitled to an opinion! I appreciate your opinion.

Well, that all comes down to the original question of what people are looking for, and I think that bears directly on your question about, "why fewer GitHub stars for X than Y."

FreHD is great for people who have a TRS-80 Model I and want to load up a bunch of games on it and be easily able to play them. And there's nothing wrong with that. But there's a (probably smaller, but still not trivial) portion of the retrocomputing community for whom that's not really interesting at all; what's interesting is to be able to reverse-engineer the machines and understand everything about them, and even modify the system and its system software. FreHD serves the former quite well, and serves the latter basically not at all.

GitHub, being a tool for programmers to share code and design information, attracts the latter but not the former. Someone who just wants to buy a FreHD and load it up with games has no use for GitHub, so it's no surprise that they won't be registering there and putting stars on things.

 

[VERAULT]

Someone who just wants to buy a FreHD and load it up with games has no use for GitHub,

Many people, myself included, build and make the projects found on Github. buying them is boring. Building them is all the fun. So Myself and other folks are allowed to have our own opinions of Github and how awful it really is.

 

[cjs]

So Myself and other folks are allowed to have our own opinions of Github and how awful it really is.

Fair enough. But keep in mind that your complaint about GitHub basically boils down to, "anybody's allowed to set up an account there and upload their projects, with no consideration about whether other similar projects exist there," and that's the very thing that allows you to go download so many different things from GitHub in the first place.

If you really object to non-curated repositories of projects, put your money where your mouth is and refuse to download any projects from GitHub.

 

[VERAULT]

your complaint about GitHub basically boils down to, "anybody's allowed to set up an account there and upload their projects, with no consideration about whether other similar projects exist there,"

No thats not my complaint at all. Please dont put words in my mouth. That was just a topical point I raised, making the same point about the internet in general as well.

If you want to know my complaints about github they are expressly spelled out on an older thread I made specifically for gripes about github. This isnt the place to rehash them; its the OPs points in question here.

 

[LambdaMikel]

@cjs, ok, so a couple of comments. First, thanks, so it boils down to

GitHub, being a tool for programmers to share code and design information, attracts the latter but not the former. Someone who just wants to buy a FreHD and load it up with games has no use for GitHub, so it's no surprise that they won't be registering there and putting stars on things.

and I agree - but that's why I started this thread, because I consider it unfair. Some people benefit from it, but not the original author. Like I said - if you use a FreHD, or any other piece of hardware / software and consider it useful, consider upvoting it on GitHub, it will likely help the developer in some form or the other.

I also disagree with the following:

What seems to have happened here is that you have no idea about how to evaluate a developer's ability to design and write code, so you've decided you'll just look at stars instead. That's not uncommon, but that's not the kind of person or company I'd like to work for, because it doesn't matter to them how good a developer I am: it matters how many stars I can gather. And I want a job building great products, not a job convincing random people on the Internet to "thumbs up" my stuff.

The latter speaks for you, and this is exactly how I think - however, a Star on GitHub is likely based on a much more informed decision and I consider this a much more valuable metric compared to other social media "thumbs up" BS. Given that GitHub is used by people "in the know" - and then you could also look at the number of forks, merge requests, etc., activity. Cloning a project in itself requires at least some skills, whereas consuming a SO answer does not. This is definitely a metric of much higher quality than upvotes on Reddit, Quora, or SO, where 99% of them answer questions of junior developers. So I think you are wrong wrt GitHub metrics - again, opinions, and no need to comment on that on your side or trying to imply that "I don't understand a thing or word" or have other mental challenges because I am writing this. Thanks. IMHO, stars are informed, and you confirm this yourself when you conclude:

So, no way that one gets a star from me.

As such, they are of potential value to the developer, and hence I conclude that it would be good if she / he got some stars! So, given that Stars are informed, we should IMHO also include other criteria than formal software engineering criteria for assessing the projects.

When it comes to assessing the quality of software, sure, the things you list are all the usual bean counter-style of arguments (documentation and what have you) - please note that I already mentioned this myself regarding FreHD in my second reply on this thread or so! -, and again, it's a question of what you value. I value ingenuity and pratical impact MORE than bean counter arguments from Software Engineering freshman lectures. I don't disagree that professional software development needs to have these quality standards met - but I am seeing FreHD as a gift to the community, and it doesn't seem to be appreciated.

And I still think that a PCB replica requires much less engineering effort and ingenuity than FreHD. And that the public recognition doesn't reflect that. What if Einstein's theory of General Relativity was rejected because he didn't use the right font, mathematical conventions, or paper quality? Well, I'm putting a here (hope it helps...)

Again, please don't feel offended by my opinion. It's just what I think. Also note that I am not making this personal... in particular, I am not trying to imply that you have mental challenges because you don't share my opinion.

So, from my point of view, this topic has been sufficiently discussed - I probably won't engage more after this last post in that regard. Again, I appreciate the discussion, and it gives me an idea or even answer to my original question: form and presentation matters more than ingenuity, and even the hundreds of people that use FreHD every day can't be bothered to show their appreciation by signing up on GitHub and leave a star. I get it.

 

[Eudimorphodon]

Fair enough. But keep in mind that your complaint about GitHub basically boils down to, "anybody's allowed to set up an account there and upload their projects, with no consideration about whether other similar projects exist there," and that's the very thing that allows you to go download so many different things from GitHub in the first place.

I thought the complaint in that thread was more along the lines of it being some huge crime that many of the repos for hardware projects on GitHub are targeted at people that have the necessary domain knowledge to contribute to the project, vs. coming with extensive professionally written documentation able to walk even the rawest of newbies through not only assembling the project itself, but gathering and using all the tools needed to do every subtask.

 

[VERAULT]

I thought the complaint in that thread was more along the lines of it being some huge crime that many of the repos for hardware projects on GitHub are targeted at people that have the necessary domain knowledge to contribute to the project, vs. coming with extensive professionally written documentation able to walk even the rawest of newbies through not only assembling the project itself, but gathering and using all the tools needed to do every subtask.

I mean thats a bit snipey and raw... but yeah something along those lines

 

[cjs]

...but that's why I started this thread, because I consider it unfair.

Well, unfair from your point of view, but very fair from my point of view, as a user of GitHub.

The problem is, you want the audience of GitHub to be a group that it isn't, so that you can see things rated by different criteria than developers use and need. That is being unfair to developers, who are looking for ratings on GitHub by what's good and useful to them, not to end users.

And really, to be fair to developers of end-user retrocomputing products, they should not have to put their code up on GitHub, or even open-source it, in order to be able to get ratings. Any hardware developer who puts her stuff up on GitHub runs the risk of it being grabbed by a Chinese manufacturer who then floods the market with cheap copies of it, probably killing her income if she sells the device herself. So under such conditions, asking developers of hardware to put their schematics and code on GitHub in order to earn "thumbs up tokens" would be very unfair to them.

Some people benefit from it, but not the original author. Like I said - if you use a FreHD, or any other piece of hardware / software and consider it useful, consider upvoting it on GitHub, it will likely help the developer in some form or the other.

Well, as someone who actually presents his GitHub projects to potential employers and clients, I disagree.

And I'd suggest that the developer of FreHD, if its popularity amongst end-users is going to be important to someone he's talking to, present something that actually shows that popularity, i.e., his sales figures, not stars on GitHub. Someone paying money for his product is a far more convincing argument that it's useful to end users than a star on GitHub.

The latter speaks for you, and this is exactly how I think - however, a Star on GitHub is likely based on a much more informed decision and I consider this a much more valuable metric compared to other social media "thumbs up" BS.

I see no reason to believe that a star on GitHub is an informed decision; it's more likely just an, "I think this is cool" or "I want this in my list of things to come back and look at again" decision. As an indicator of developer skill, that's not nearly as useful as someone upvoting an answer on Stack Overflow, which almost invariably means, "This person gave me useful technical information that helped me solve a problem" or "this is good and well presented technical information that answers the question."

Given that GitHub is used by people "in the know" - and then you could also look at the number of forks, merge requests, etc., activity.

You could, but those metrics are just proxies, and often enough poor ones at that. Forks are more often a bad sign than a good one; long-lasting forks usually indicate a project that won't add features that users want or, worse yet, a project that's no longer being maintained. Forks also exist because you have to fork in order to create a PR; some people delete them afterwards (I usually do), others don't.

PRs are also just a proxy. Sure, a good project that needs better features can generate PRs, but a project full of bugs can also generate PRs to fix all those bugs. A project with a number of committed developers may generate few PRs because developers simply commit their code directly, whereas a project making much less progress may have many more PRs because most of the code comes from "drive by" developers (who by nature are much less familiar with the project) rather than core developers. And it's important to note that in general projects that take contributions more through PRs than "core" developers will be slower moving because PRs are a very high-ceremony, process-heavy way of getting code on to the main branch. (This is by design: they're to allow developers not familiar with the project and its processes, and with poor communication links to the core developers, to contribute.)

Cloning a project in itself requires at least some skills, whereas consuming a SO answer does not.

Cloning a project requires pressing a button. Voting on an SO answer requires pressing a button. Starring a project on GitHub requires pressing a button. That's about equal in skill level as far as I can tell.

This is definitely a metric of much higher quality than upvotes on Reddit, Quora, or SO, where 99% of them answer questions of junior developers.

Sure, which is why I already explained to you that all of these "thumbs up" metrics alone are near useless. (In fact, I explained in great detail the problem with the upvote metric on Stack Overflow, and how to get past it to the useful data.)

Looking at that those data takes work. Not a huge amount, but you actually have to read the answer or the code or whatever and use professional judgement as to whether it's well done and what it says about the skill level of the writer or developer. I know you wish that there were some magic number that you could look at, rather than having to have that level of skill at evaluation, but there ain't, and there never will be, especially when that magic number involves how many people click a "thumbs up" button on the Internet. And of course it's even worse when the "thumbs up" is not necessarily a rating, but a bookmark, as stars are on GitHub.

...and hence I conclude that it would be good if she / he got some stars! So, given that Stars are informed, we should IMHO also include other criteria than formal software engineering criteria for assessing the projects.

Well, I'm glad you agree with me that formal software engineering criteria should not be used for assessing projects.

From many of your comments, including your misunderstanding of the difficulty levels of the two projects in question, and that you appear to think that I was judging the projects above by "formal software engineering criteria," I think you are not a developer of hardware and software.

I was judging the two projects not by any formal criteria but by how easy the developer made it for me to understand their system, make their hardware and use their code. I.e., I was looking at it from the point of view of, "can I download this and easily make the device" or "can I download this and easily find and fix a bug"? The difference between the two projects in those areas is vast, and easily discernible to anybody who actually does these things.

But someone who doesn't do these things is likely to confuse actual usability for developers with:

...all the usual bean counter-style of arguments (documentation and what have you)

as you do.

....but I am seeing FreHD as a gift to the community, and it doesn't seem to be appreciated.

Well, part of that is because it's a "gift" that's such a serious PITA to actually make use of in its form on GitHub that even I, who am perfectly capable of of making one from that repo if I were willing to put in that much work, would just go out and buy one instead if I really wanted one. Going through that mess is not worth saving $70 or whatever it costs.

As I said in my previous message, go and generate the Gerbers, build the software, etc. yourself, and see just how hard that project makes it. If you're not capable of doing this, you're not capable of judging the quality of the design files, source code and documentation there.

And I still think that a PCB replica requires much less engineering effort and ingenuity than FreHD.

Well, now that I've had a closer look at it, I'd say the PCB replica requires somewhat more ingenuity on the hardware side (though lesson the software side), but far more engineering effort. I say this as someone who knows and has done the kind of development and debugging both projects need.

And that the public recognition doesn't reflect that. What if Einstein's theory of General Relativity was rejected because he didn't use the right font, mathematical conventions, or paper quality?

Papers get rejected all the time because they don't use the right mathematical conventions: if someone can't read the equations, they can't understand the paper. Papers also get rejected all the time because of poor writing: again, if someone can't understand it's not a good paper. The idea may be great, but if it's not communicated well, it stays with the author rather than goes out to the world.

(By the way, I've written an academic paper, shepherded it through peer review, and had it accepted, so I'm pretty familiar with the process.)

Again, please don't feel offended by my opinion. It's just what I think.

I'm not offended; I'm just trying to explain to you where you've gone very wrong in your idea of how the world should work and how you're evaluating these projects.

 

[cjs]

As a final note, let me leave you with a couple of exercises that will make it very clear to you what the problems are with the FreHD design files and code that are in that GitHub repo.

1. The easier one: generate a set of Gerbers and submit them to JLCPCB or PCBWay (or whatever your favourite board house is) to get the board manufactured. Compare that with what you need to do to do the same for the Model I replica PCB.
2. The more difficult one: fork the FreHD repo and swap two pins on the microcontroller of the FreHD (e.g., a pair of control pins for the switch matrix), updating the software to match and rebuilding it. This is a fairly trivial thing that involves no changes in functionality, and so doesn't require much domain knowledge.

I'm absolutely positive that you'll find both these tasks very difficult; but here's your chance to prove me wrong. If you can do them rather trivially, and explain just how trivial it was, in a way that someone of equal skill can easily replicate what you've done, I'll be very impressed. But, knowing how to do these things myself, I'm absolutely sure the process will be a huge PITA. I suspect you will probably end up here, actually.