The idea behind that is that people usually don't run RHEL for fun, there is mostly a business need for that. Especially since there are distros like Alma Linux out there, which you can use with XPipe for free.
You can go to Settings -> Synchronization and enable the remote git repository sync. If your team members synchronize with the same remote repository, this should effectively allow for a team collaboration.
If you want to keep using emacs, there is the possibility to launch any custom editor in xpipe via a command. You could use emacs as your primary editor with it.
Thanks for your feedback. To answer your questions:
3. Making the source available would technically be possible, but I would have to consult with a lawyer for that first on how such a thing would be implemented. But I can definitely see this being a feature for the enterprise plan if the customer is interested in it.
4. XPipe uses JavaFX as the GUI framework. It might not be the most fancy and modern solution out there but gets the job done. It is still maintained, but that concerns mainly bug and security fixes. In terms of new features there isn't that much happening but that's not that bad as the desktop hasn't changed a lot over the last decade. There might be more modern solutions out there like Jetbrains Compose, but the advantage of JavaFX is that it is very stable and mature. There's also a good ecosystem of libraries for it.
5. In terms of license enforcement, it's pretty lenient. You only have to validate the license after at most 7 days, so if you are offline for a period of time it will work fine. If you are working on a fully offline system, there is also the possibility to request an offline license that will not require any internet connectivity. See https://xpipe.io/pricing#faq for that.
6. I try to do my best shipping a stable product. I think most developers would probably want to do that, but in practice it's usually investors or management pushing down from above to get features out quicker. I guess I'm in the fortunate position right now being able to choose my own development pace.
Nice thank you, I've been considering playing around with JavaFX for quite some time. Do you have any advice for someone getting started who has quite a bit of Swing experience but no JavaFX?
I think it's good to be aware that there is a lot of bad tutorials/libraries for JavaFX out there. Also many StackOverflow answers are quite outdated as the popularity hit a peak like a decade ago. Also don't use FXML (the weird declarative way of creating GUIs).
I think the best way to get started would be to download the sampler application from https://github.com/mkpaz/atlantafx. That is state of the art, good implementation. You can play around with it and jump to the source code to see how it is implemented. It contains almost everything an application needs.
Also depending how old your general Java knowledge is, the modern way of creating applications is through the module system and the jlink/jpackage tools. There are many outdated solutions for application packaging out there as well. If anything you see is using the classpath, builds jars or fat jars, or is using external tools outside the JDK, it's probably old and no longer appropriate.
I'm not deeply familiar with the vscode internals but figured that they were doing something similar as many issues and error messages that were thrown by shells and various programs led me to some vscode issue with the same problem many times.
Because it turns out in practice some shells and programs do not like being run in the background in a dumb terminal as this is an obscure use case.
Well it is open-core on GitHub right now. I think full open source is going to be difficult if you're trying to sell it. At least in the desktop application space with no account setup or other service dependency it's complicated as anyone could circumvent paying by cloning it and commenting out a few lines.
But I can fully understand your concerns, establishing trust is important. At the end of the day it's up to you whether you feel comfortable enough with it.
On a fundamental level, the difference is that winscp is based on certain protocols like SFTP and ships their own SSH implementation for that. XPipe uses your existing ssh CLI client to accomplish the same thing instead. This makes it more flexible as it integrates with your SSH local config out of the box. This also allows you to use any arbitrary terminal emulator to open connections, in contrast to WinSCP.
But there's also much more included in XPipe that you can't find in WinSCP. There is SSH tunnel support, container support like for docker, dynamic root elevation in a file browser session without having to restart, a scripting system, a VNC viewer, an RDP launcher, and more.
