I agree that Mensys, and the developers, don't have enough people helping. Of course, it would help those who do attempt to help them, if they would document their work in a comprehensible way (the current docs are a kludge of, sometimes incorrect, information, that means absolutely nothing to the average user). It would also help, if they would take the extra few minutes to package the updates into the existing WarpIn package, so install, and uninstall, is easy, and correct, every time. Trying to find all of the places to do the updates (or downdates) is a challenge, and it doesn't help when they add new programs, like ACPIEXEC.EXE, with no clue as to what it does, or where it should be put (the program is in the betazone distributions, but not in the eCS 2.0 Silver install). This is a two way street, but doing it the way that it is being done, is not working, and that is mostly because the average user is so afraid to try it out, that they refuse to do it. It would also help, if automatic log collection, and problem reporting, was available. Of course, all of those things take developer time, although someone with some knowledge of how it all works, and what information is needed to analyze a problem, could probably build something to do the log collection, and problem reporting. Building a WarpIn installer can be part of the program build process.
I don't think it would be right to open testing to those who don't own a version of eComStation. After all, Mensys does need something to justify the cost of eCS, and supply an incentive for OS/2 users to upgrade to eCS (and it is definitely an upgrade), so they can recover the cost of development. However, it may be a good idea to open testing, perhaps with a time bombed version of ACPI, to those who do have a license for eCS. A time bomb would also ensure that those who do use the beta versions, won't use them forever.
As for how the development is being done, I suspect that they are trying to do it properly. Unfortunately, nobody else is doing it properly, so they end up in a situation where they need to write special code for every machine, and BIOS level, that is built, to work around the differences. It appears that MS, and Linux, have taken the approach to totally ignore what the machine manufacturers put into their machines (which is often incorrect), and simply do it themselves. That is not the way that it is supposed to be done, but it seems that it is the only way to make it work on every machine, without having to accommodate the differences that exist. The fault goes back to poorly written specs (probably heavily influenced by MS), that can be interpreted in more than one way. Of course, every manufacturer manages to find a different interpretation, and then they change it when they find out that what they thought was right, doesn't work. So, the problem is, that trying to "do it right" has turned into a disaster, but it seems to be too late to change directions. The other problem seems to be that they are using the Intel version of how it is supposed to work. That, mostly, works with Intel hardware, but seems to be incompatible with AMD hardware. You can't just leave a good portion of the market without support. What can be done about that situation is unknown (to me). Hopefully, somebody can find an answer, soon.