As I mentioned in reply to another comment of yours, the main difference in my opinion here is that I am posting this as an individual one-man company compared to something like Oracle. And the Oracle free tier still requires you to sign-up and provide your data. This free version does not have such a commitment.

A lot of projects are sharing status updates and development news and various platforms, some on lemmy as well. On average, I post status updates every 1-2 months when there is something to share. And yes this is self-serving, I am advertising my project after all.

I think blocking me would be a bit overkill? You could also just downvote the posts you don’t want to see and move on, you don’t have to read my posts if you don’t like them. That is up to everyone themselves. People who are interested in these posts can do the opposite.

In this case I am trying to market XPipe as a one-man company. Yes, that is technically still a company, but it’s a little bit more personal. Because here you are not talking with the marketing department of XPipe but with the developer of it.

Yeah the pricing model requires the homelab plan for larger Proxmox cluster setups with multiple nodes. However, there are no limits to what you can do with that one Proxmox node. You can fully use every feature with it there is no limit on the amount of VMs you can manage in the community version on that node. Just when your homelab setup is larger and has multiple nodes, it requires the homelab plan. And at the end of the day, I think you can form an informed opinion on whether upgrading to the homelab plan would make sense to you after using the one node for some time. If you don’t think the saved time and effort with XPipe is worth the 5$/month for you, that’s fine. Everyone can determine that for themselves.

Wow, I missed quite a discussion up here when I was away.

I would argue this is part of this community, a showcase and status updates of projects that can be useful for the selfhosted community. I understand that there is a focus for completely free projects in here, but some tools showcased here also include a paid plan. In this case I’m trying to make a living out of this, so there is a payment model in place. I limit my posts to only major updates, so the post frequency is dependent on the development speed.

There is a free community plan available that covers many use cases, there is no need to pay for XPipe unless you want to fully commit to it and use all of its features.

Thanks for your video showcase back then, it really helped the project get the initial traction.

The project was definitely rough around the edges back then. It held together somewhat but I would say it was around a 50/50 chance that it would work as expected for a new user. I think that has been the biggest improvement since then, the reliability and handling of edge cases so that the vast majority of users can now use it as they expect without issues. That was made possible with the help of the community which reported and tested all kinds of things I could not have done on my own. Having a community running a diverse set of systems helps out development immensely.

You can if you’re interested in any status updates

Yeah I can do that

It is a frontend for standard CLI tools yes, but it comes with many additional features. The focus is especially on integrating standard CLI tools with your desktop environment and other applications that you use like editors or terminals.

For example, of course you can just use the ssh CLI to connect to your server and edit files. But with XPipe you can do the same thing but more comfortably. You can source passwords from your local password manager CLI, automatically launch terminals with the SSH session, edit remote files with your locally installed text editor, and more.

Of course you can do this also with tools like putty, but the difference here is the integration. Other tools ship their own SSH client with its own capabilities, features, and limitations. They also have their own terminal. XPipe preserves full compatibility with your local SSH client and terminal. E.g. all your configuration options are properly applied, your configs are automatically sourced, any advanced authentication features like gpg keys, smartcards, etc. work out of the box.

The same approach is also used for the integrations for docker, podman, LXD, and more, so you can use it for a large variety of use cases.

Yeah it is similar to Remote Desktop Manger or Royal TSX but also tries to go a different way in many aspects. The goal of managing your servers is the same, but how it is effectively accomplished differs significantly.

Can you elaborate on what you mean by your problem with opening multiple terminal windows? I am not aware of such an issue, so maybe you can report it on GitHub with a few more details

Yeah the commercialization model is not perfect yet. Ideally the community edition should include all normal features required for personal use. Would that only be like one machine to connect to or many? I was planning to experiment with allowing a few connections where a license would be required in the community version.

Yeah I can understand why some people feel that way. Originally this closed part only concerned a very small part, but due to necessary subclassing of that implementation, that kinda evolved to the whole shell handling interface. I always wanted to refactor that aspect and decouple it such that these parts can be included in this repository, but never got around to it.

Maybe in the future this can be properly addressed because it’s more a matter of a not well thought out structure rather than hiding crazy secret implementation details. The whole project’s vision moved around quite a lot and most stuff was conceptioned before there was even a thought to try to sell it.

I see your points. In the end it boils down to the fact that there is no clear split between free and paid features in the codebase itself due to the chosen commercialization model. The paywall that is in place right now is mostly artificial because the code is the same for all systems. So even if I wanted to, I could not implement the classic open core model with a fully open source base version. I could have used a different approach to start out, e.g. only locking certain features behind a license and not certain remote systems like it is currently done. That would have probably allowed me to implement the more classic open core model. But the current model also has its advantages in other areas.

You can just ship your own version of the repo if you want due to the apache license. To properly run this the user would however still need the regular xpipe installation which contains some parts that you would still need to properly make use of it. I think the term basic core functionality can be interpreted differently here. So if you are talking about being able to use all the nice features that make xpipe stand out, then yes these non-open-source components are necessary for core functionality. If you are just talking about being able to run the application and do limited things with it, then they are not.

Yeah maybe the term open core is not the best way to describe it as it doesn’t entirely fit the pattern. I’m open for better suggestions where I can still somehow highlight that most of the application is open source (in terms of LOC, it is around 90% in that repo)

From your description I would say yes.

You always have to fiddle around a bit with SSH jumps and fowards as there are two different ways in xpipe to handle that. You also have to take care of your authentication maybe with agent forwarding etc. if you use keys. But I’m confident that you can make this work with the new custom SSH connections in xpipe as that allows you to do basically anything with SSH.

In summary, there are a few components not included in the public repository, mainly because it is very difficult in practice to get people to pay for a 100% open source tool where they can just clone it and remove any license requirement in a few lines. So it is not a fully Apache licensed application, it’s core is. There is only one release version so it is difficult to provide a separate apache-only installer, mainly for technical implementation reasons. Some codebases can’t be perfectly split into free and non-free parts that can be shipped separately. These not included components are the license handling implementation, the low-level shell process handling implementation, and the CI/CD scripts for distribution.

The EULA is just standard terms like don’t try to circumvent the license requirement, if you buy a license don’t share it with other people, some warranty and liability stuff, etc.

If you build a development version from source, it requires to have another xpipe installation present where it can utilize some of the shipped components from it. But you can fully run and modify that development version. They are not necessary for basic core functionality but it doesn’t work without it as the license requirement could be disabled easily then as I mentioned before.

Overall I think this split is the best solution considering all factors. I understand that some open-source proponents don’t like that. But I think since the application core is open source, it still has the good effect of establishing trust because anyone can take a look at how your data is handled internally, which is especially important in this context where a lot of sensitive information is used.

It’s not really related at all.

It is basically a graphical wrapper around your CLI tools like ssh, docker, kubectl, and more that gives you the features you know from tools like graphical SFTP clients but supports much more types of connections and allows you to use your favourite terminal and editor for your remote connections.