@mariokleiner Any update on macOS ARM and Windows licenses? My lab is keen to work out how to move forward with this.
Will the support token route still exist, or will the licenses be a replacement?
P
My hope is to have something for sale sometime in mid November maybe, the earlier the better. But the launch date had to be shifted so often (beginning 2024 → Spring 2024 → VSS in May → Summer → Late summer → Beginning of October → Beginning of November → Maybe mid November??) due to various major screw ups of some people involved, and also the usual amounts of disasters or road blocks that one could prevent or solve with money if one had money, that I don’t know if that is a realistic guess, or just unfounded optimism and wishful thinking.
Right now, after over 2.5 months of 80+ hour work weeks with no breaks, and one false start, which cost me over 6 weeks of wasted work, I have the license management part almost ready. Turns out that implementing license checking and management for open-source software that has to run on three different operating systems, two to three different scripting environments and multiple processor architectures, while maintaining an open-source development model is an even bigger nightmare to implement than even I imagined.
We also signed up for a seller account at Fastspring last week. We haven’t defined the actual products yet, and any product we define will be subject to review and approval by Fastspring. There are constraints to how and what one can sell exactly, because the online shop / reseller obviously wants to maximize their profit while minimizing their support overhead, financial risk and legal liability.
I also still wanted to do more refinement work on the Apple Silicon Support, beyond what you had already for testing. Not sure if it makes more sense to push that out immediately to get sales starting faster, or to spend more time on it.
The initial offering for what to sell is still not defined. Again, we need to start simple if we want to start this anytime soon.
Results from past user surveys tell us that the typical average lab has about 6 to 10 people, and uses 6 to 7 Psychtoolbox installations on lab machines. The much bigger sample size survey suggests 10 people per lab, 6 PTBs. The more recent survey with a much smaller sample set suggests 6 people per lab, 7 PTBs.
So my thinking atm. is that a standard license should include the ability to run PTB on about 6 - 10 (operating system + physical machine) combos, probably at a prize point around 200 - 250 Euros per year + applicable taxes. E.g., 6 combos for 200 Euros, 10 combos for 250 Euros. Something like that.
Maybe more variants like 3 combos for 100 Euros, or 1 combo for 50 Euros for an individual.
What’s not clear is what would be needed beyond that, or how to prize it. But maybe some subset of the above will be good enough as a starter.
In the end time is of essence, as the whole project is delayed by more than six months now, and we are running out of funding fast, so if this new model doesn’t launch and sell well very soon, Psychtoolbox will be over.
In the long term - assuming the new business model will actually work and there will be a “long term” - probably not in its current form. The current model was mostly a big failure, both in terms of money earned and in effort expended to earn what little money it made. I would like to get rid of it.
I intend the upcoming software license to give users some kind of very basic support. If you have a PTB software license key for running the future macOS and Windows versions, PTB will generate a type of authentication token that I can quickly verify, to prove to me that you bought such a license. The support you’ll get out of that will be some basic support, pretty much at my discretion, without contractual guarantees about response times or minimum amount of support time provided, or that I’ll support users at all if they are too difficult to work with or the problem is too complex/time consuming to handle atm. It will be more of a “goodwill” bonus service, not something contractually guaranteed. I want to keep it simple at the beginning, and combining/conflating a software license with some support contract could cause extra problems or friction with our future online shop provider/reseller, or unwanted extra financial liability for my employer. We usually can’t sell licenses to our users directly, but only through a reseller/merchant of record (MoR), ie. an online shop that provides MoR services. The reason for that is the complexity of handling different payment methods, fraud prevention, selling into hundreds of countries in the world - each with its own sales laws, and the nightmare that is VAT/sales tax handling and remittance for digital goods and services, which differs in every single country and sometimes even in every single state of a country (e.g., the US) and sometimes even day of the year (“sales tax holidays”). We’d need an army of tax accountants and bookkeepers to deal with that, and that is unaffordable. So we need an MoR and that MoR has to do their own risk assessment if they want to sell our products at all, iow. if the expected amount of money/profit for them is worth the trouble. Therefore it is better to keep it simple and only sell a bog standard subscription software license at the beginning.
Another problem with combining will be how to actually price that.
The old support membership I intend to keep until we know if or how well the new model works.
I assume we will continue to offer some extra paid support, just similar to what we have now as “extra work hour packages” on top of paid support memberships, so users can buy extra support. But the whole discount system for loyal and supportive users that we have right now, I intend to kill off as well. Substantial discounts seem to be an incentive that works well in the rest of the world, but apparently not with our users - selling only a total of six such discounted packages in three years.
We also need such an additional support model until I know how we will deal with Linux licensing in the future. From a purely commercial standpoint it would make sense to require paid software licenses for Psychtoolbox on Linux, just as we will require on macOS and Windows. Our best estimates of installations suggest that as many labs (about one third) use Linux, as do macOS (about one third), so financially we potentially leave a lot of money on the table by exempting Linux from the new scheme. However, there are various philosophical, ethical, political, organizational and technical reasons to exempt Linux from the new scheme at least at the start. Even in the long term I’d like to keep at least some PTB variants for Linux free as in beer. Until these questions are sorted out, I won’t charge for Linux PTB. But users still need to be able to buy paid support for Linux.
2 Likes
Awesome, thanks Mario.
Glad that is it round the corner. These things always do take time.
I really hope that this will put the excellent PTB on a firm footing going forward.
Peter
Hi Mario, I’ve been away from the forums for a bit, but thanks for an informative post!
This sounds very promising, at least for the fact is that Fastspring support’s Asian (Chinese) payment systems which the previous option didn’t, I hope that Chinese payment options will make it through any review, PTB is used dominantly on Windows by quite a large number of groups and facilities (i.e. MRI scanners, even in hospitals etc.).
One problem here is bitrot, someone install PTB years before but it never gets updated: fixed bugs just get worked around, improvements ignored 
A first beta release for macOS on Apple Silicon Macs is now out, in case anybody is bored under the christmas tree or their end of year plant of choice:
When looking at our so far 301 trial signups for PTB 3.0.20.0, of which 107 (~35%) are for PTB on macOS, I noticed that about a non-trivial fraction of about a 20% of Apple Silicon macOS users are running PTB on Matlab for Intel Macs, via Rosetta2 emulation.
Psychtoolbox 3.0.20.0 was not prepared to deal with that. It assumed it was running on a Intel Mac and didn’t adapt to the special conditions on Apple Silicon, so visual stimulation timing and visual stimulus presentation was somewhat broken.
I have now released Psychtoolbox 3.0.20.1, which tries to detect this situation and tries to treat such a setup the same way as a native Apple Silicon setup, so users using such a Rosetta2 setup should upgrade to 3.0.20.1.
That said, it is unknown what kind of side effects running under Rosetta2 emulation can have, and if macOS treats software under emulation properly enough for the requirements of our type of applications. I also can’t really test such “Intel Matlab via Rosetta2 emulation on Apple Silicon” setups for correct operation, and don’t intend to do so in the future.
Therefore a reminder that if you have an Apple Silicon Mac, you should use native Apple Silicon Matlab (R2023b and later) or native Octave from HomeBrew for best results with Psychtoolbox.
1 Like
I think it certainly is a user’s responsibility to ensure they have the native version of MATLAB/Octave installed. The native version of PTB+MATLAB is working incredibly smoothly, great for development purposes anyway. MATLAB itself is more fluid overall (GUI feel, startup speed etc.) than on my theoretically more powerful Dell workstation.
Probably mostly determined by SSD drive speed, given what a huge memory hog Matlab is, especially during startup and first use of any function like the Matlab editor. Generally for application startup or OS boot, SSD’s are the main boosters. I think the Silicon macs have relatively fast builtin SSD’s. My Windows-10 development machine is still using a good ol’ hard disc drive, and I have to switch it on half an hour to an hour before I need it, because booting up, logging in etc. can easily take that long on a current Windows-10. It can take 10+ minutes to launch Matlab and multiple minutes to pop up the editor after edit foo.m.
I’m sure a fast SSD helps, but I think the much larger memory bandwidth with unified memory also works wonders. I run local LLM models with LM Studio, and again in theory my Ubuntu workstation has a dedicated NVME M.2 SSD, AMD RDNA2 RX6800 16GB dedicated GPU + 32GB system memory and 8/16 core i7 vs. 8 core M2 macbook air with 16GB shared both CPU and GPU — and yet the macbook is 3X faster at LLM inference. The AMD GPU is specced to have better memory bandwidth (512GB/s) vs. the M2 (100GB/s) but that is not reflected in the overall performance (the unified memory itself really makes a difference). When Phoronix tests, Ubuntu is a clearly faster OS than macOS overall. So this is hardware, there is really some magic in unified memory I think, and maybe the SSD controller works better with the system overall.
I also made a recent mistake of installing Windows 11 on a hard disk. 8 minutes to boot, many minutes for MATLAB, everything just takes ages = basically unusable. Yet my Raspberry Pi boots Debian to desktop in just over minute running off a generic memory card!!!