Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wavebox 10 source #1132

Open
Thomas101 opened this issue Nov 27, 2019 · 21 comments
Open

Wavebox 10 source #1132

Thomas101 opened this issue Nov 27, 2019 · 21 comments

Comments

@Thomas101
Copy link
Member

Here at Wavebox HQ, we've been busy rebuilding Wavebox from the ground up and rewritten it directly on top of Chromium. This is a huge step forward from the old version that runs on top of Electron. We've also taken the tough decision not to publish the rewritten version on Github.

One of the main driving factors of this has been the time it takes our small team to provide a buildable toolset that can facilitate building from Github vs the time we could be spending on new features as requested by users.

For comparison, Electron has been designed from the group up to get started quickly and easily and this is echoed in the Electron version of Wavebox. It's installable and buildable with little more than 3 commands and only takes a few minutes to compile. In contrast building Chromium from source is much more involved, requiring a specific build environment and also taking at least 10 hours to build on a top-of-the-range MacBook Pro.

It's because of this we've decided not to open source the new version of Wavebox, as we feel that the time we're going to spend providing build tools and build support could be better spent working on features that people have been asking for. Already, we've seen that devoting this time to the main app has allowed us to bring some amazing new features into Wavebox 10, including privacy locking, broad extension support, massive performance improvements and more. If you want to try it out, we'd love to hear what you think!

We're working on some new developer tooling for those that want to customize and extend Wavebox 10, this will be an enhancement to the chrome extension API that we already ship with. If this is something you're interested in, drop support an email and we'll open up an early preview when it's ready.

So what happens next...?

  • We've already renamed the Github project to be Wavebox Classic, but that's about the only change.
  • This source code, repository and existing downloads on Github will stay exactly where they are.
  • We'll be pushing patch releases to Wavebox Classic until everyone's in a position to move across to Wavebox 10.
  • Free users can use exactly the same features in Wavebox 10 as what they can currently.
  • Paid users just need to sign in to Wavebox 10 with their account and will have all the new features ready to go.
@ToLive
Copy link

ToLive commented Nov 28, 2019

Not wise decision on my opinion. Back in 1+ years I personally chose Wavebox because of it's openness. Man, I give all passwords to this app. Now it will be black box and I have to trust. I know that not everyone check the source, but have open source is quite an advantage over competitors.

@ToLive
Copy link

ToLive commented Nov 28, 2019

Anyway I will stay with you but that a pity that you lost such a great advantage.

@logankoester
Copy link

I'm really very worried about this decision.

@kendocode
Copy link

kendocode commented Dec 6, 2019

Paid users just need to sign in to Wavebox 10 with their account and will have all the new features ready to go.

Not exactly, at least in my experience. I just had to set up Windows for the first time in a while and downloaded Wavebox because I've been using it since wMail and consider it indispensable for a work machine. But WB10 installed on Windows, and it wouldn't import the v4 config from my Linux export. So, unless I missed a step (which I grant is likely) anyone choosing to go forward with the black box version has to recreate their entire setup from scratch. (Which is just signing in to all the services and arranging things, not as bad as a stick in the eye, but not as nice as importing a config file either.)

...we've decided not to open source the new version of Wavebox, as we feel that the time we're going to spend providing build tools and build support could be better spent...

Is there really no middle ground between devoting excessive resources to tooling and support with open source and going completely opaque? It is open source after all. Your obligations beyond providing the code are entirely what you make them. You could just say "here's the source, now you're on your own". Anything beyond that on a best effort basis I would think to be perfectly reasonable for a small team trying to make a commercially viable product. While this is a legitimate issue, I can't help but feel it's not the main one.

We'll be pushing patch releases to Wavebox Classic until everyone's in a position to move across to Wavebox 10.

Any time line on this? I ask because, as I mentioned, I have a "just so" config on Linux. I'm a current paid Pro user. But I chose WB because it was open source. I'm all for performance enhancements and features, but not at the expense of the ability to read the code. I hold out a faint hope that your team will reconsider its decision, but it doesn't sound like you're open to that, and since most people evidently don't care to the point they will forego the app I suppose there will be no real incentive for you to do so.

So I'm wondering, should I bite the bullet and wean myself from this wonderful tool now, or can I carry on a bit longer? What criteria will you use to decide when everyone is "in a position to move across" to the black box version?

Thanks again for the work from wMail up to now. I think ditching (open source) Electron to build directly on (open source) Chromium puts you in a great place going forward. Alas, I will not be able to "move across" if you must completely abandon open source to get there.

@bkuri
Copy link

bkuri commented Jan 15, 2020

Looks like this decision is final. Pity.

I was maintaining one of the wavebox AUR packages up until a few minutes ago, but I can't keep on doing that in good conscience without having access to the source code (kind of goes against the whole Linux philosophy and all that).

@Thomas101 you might want to switch your license, since the MPL is pretty clear with regards of source code availability.

I'll still remain a Pro user for the time being, but that will likely change as well.

@logankoester
Copy link

Can't say I blame you. I'm sticking with the old version for now.

@lots0logs
Copy link
Contributor

lots0logs commented Jan 15, 2020

@Thomas101 Long time Pro user here. I think you are making a mistake. I find your explanation to be suspect and lacking your true motives behind making Wavebox closed source. The author of open source code is under no obligation to provide support for 3rd-party devs to build and tinker with their code. It should be possible to build it, yes, but that's for devs with the proper skills to figure out for themselves.

One of the main reasons I chose to use Wavebox was because it provided me the option to fix any annoying bugs and/or add new functionality myself if I ever wanted/needed to. With that option taken off the table now, I am not sure I want to continue using it. That's especially true when considering security. A black box that only your devs can see is not something I feel comfortable trusting with all my accounts/logins. I do hope you will reconsider and change course on this.

@schmunk42
Copy link

You make similar errors as Franz and Rambox did. I was really convinced by the strategy, but this makes me really think about cancelling the subscription and start over with a new app, again.

@sztomi
Copy link

sztomi commented Jan 26, 2020

You make similar errors as Franz and Rambox did. I was really convinced by the strategy, but this makes me really think about cancelling the subscription and start over with a new app, again.

Very well said, I'm really sad to learn about these news. I might cancel my subscription over this as well. Here is a peek into the state of Rambox after going closed-source: https://github.com/ramboxapp/community-edition/issues/1954

It's because of this we've decided not to open source the new version of Wavebox, as we feel that the time we're going to spend providing build tools and build support could be better spent working on features that people have been asking for

@Thomas101 You really should not conflate access to the source with facilitating builds by external contributors. No open source license requires that. Leave that to people who want to do it in your community; they will figure it out. I hope you will reconsider.

@logankoester
Copy link

Hey guys, my Wavebox subscription is up for renewal soon and I haven't yet found a suitable alternative to use until this issue is resolved. Any suggestions?

@sztomi
Copy link

sztomi commented Feb 3, 2020

@logankoester I'm testing out https://github.com/getferdi/ferdi - depending on your usage, it might not be on par, but for my usecase it's pretty good.

@logankoester
Copy link

This looks great, thanks @sztomi!

@dafeder
Copy link

dafeder commented Feb 5, 2020

The new version looks fantastic, but abandoning FOSS is disappointing and frankly feels a bit dishonest. I am very sympathetic to the time suck that maintaining a true developer-friendly open source project represents. But if that's not possible right now, why not simply relax the build tool support at least temporarily but maintain the license and code transparency?

@sztomi
Copy link

sztomi commented May 19, 2020

After a few months of testrunning, I completely moved to Ferdi. Canceled my subscription with a heavy heart. I did some soul searching and honestly, I didn't even want to look at the source code myself. So why am I annoyed by this? I came to the conclusion that it's because:

  • When I signed up it was FOSS and supporting such business model was one of the reasons I signed up
  • The argument why it becomes closed source feels dishonest and counterarguments were not addressed (see above: conflating access to source code with access to build infrastructure)

@bkuri
Copy link

bkuri commented May 20, 2020

I have also moved to Ferdi. Not as nice as wavebox but at least it's open source.

@schmunk42
Copy link

Ferdi looks really promising, I am willing to accept some minor drawbacks for open-source.

@ToLive
Copy link

ToLive commented May 25, 2020

I've tried Franz, Ferdi, Rambox, they are very poor competitors to Wavebox. Wavebox is a product, and I see what I pay for. Constant updates, bugfixing and so on. And I understand that it is small company. If maintaining open source code and build tools started eating too much time, then dumping it is acceptable decision to me. Still, in my opinion, it is very open and communicating company.

@zocker-160
Copy link

zocker-160 commented May 17, 2021

I have switched to https://singlebox.app/, which is IMO the best open source alternative out there.
Source code can be found here and the project is very active.

@lens0021
Copy link

I have switched to singlebox.app, which is IMO the best open source alternative out there. Source code can be found here and the project is very active.

The github link seems to have nothing now.

@zocker-160
Copy link

zocker-160 commented Jan 31, 2023

@lens0021 yes the project sadly went closed source :(
https://github.com/webcatalog/webcatalog-legacy

@lens0021
Copy link

How about BSL (Business Source License)? It is not an OSI Approved License, but at least the source code is readable for the public.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests