mailsync repo not accessible -- not open-source? about mailspring HOT 15 CLOSED

Hey folks! Thanks for creating this issue @severin-lemaignan - you're correct that the mailsync codebase is currently closed source. I'm sorry the lack of source is a show stopper! If you're concerned about possible nefarious code, you should still be able to wireshark it (it uses the SSL trust chain on your machine, so compromising one of your own root certificates would allow you to MITM the requests), or sandbox the application behind something like Little Snitch. The mailsync process connects to the Mailspring API to sync the metadata that powers read receipts and link tracking, etc, but that's it—it should continue to work fine if you block those requests.

You're definitely right that I could post the source without warranty. I guess I should say that, in addition to the rationale in the ROADMAP, I am also interested in keeping some level of control over the source to ensure that Mailspring is able to hit the "1,000 paying pro users" goal that will make it a healthy, maintained product indefinitely. (The goal is to use monthly revenue from users' subscriptions to pay one or more maintainers and/or put bounties on popular feature requests.) I'm a huge fan of open source and will definitely re-evaluate open-sourcing it as the community grows!

from mailspring.

@louim thanks for pointing me to that page. While I understand the rationale (I'm indeed fully aware of how time & energy consuming the 'open-source commitment' is), not having a fully open-source application is going to be a show-stopper for many of us.

@bengotow, if your reasons for not opening mailsync are indeed purely practical, why not making available a tar.gz of the mailsync source, with both simple yet complete compilation instructions and a clear disclaimer: "I do not provide any further support for that code"?

from mailspring.

Hey! There is a note in the roadmap about why mailsync is closed source.

from mailspring.

@bengotow For what it is worth, based on my experience those that would take the time to compile mailsync from source rather then download prebuilt binaries are likely to be experienced devs that would prefer a 100% open source solution and less likely to pay for pro because they would rather "roll their own." Keeping it closed source may turn away a few that might convert to paid, whereas I would suspect you would loose a lot less of paid users to open source when compiling your own mailsync is a hassle outside of development. The thought of dealing with compile errors and re-compiling on every update has me running to the prebuilt binaries, but on the other hand I'd love to hack at the mailsync to help debug issues!

Either way, I am a huge fan of the project and I wish it and you all the success and look forward to contributing where I can.

from mailspring.

Hey @bengotow! I absolutely understand your hesitation to open source the Mailsync code at this point, from a business perspective.

I just want to encourage you to strongly consider open sourcing the code at some point; if not now, perhaps later. I know that I myself (and many others judging by the responses here) would highly appreciate being able to take a look under the hood.

I think Mailspring has the potential to be one of the best cross-platform mail clients out there, and I applaud all of your hard work so far!

from mailspring.

If you're concerned about possible nefarious code, you should still be able to wireshark it

Unfortunately using Wireshark gives one zero assurance here. For example there may be nefarious code which is only triggered by certain requests (for example an email with specific header) and Wireshark wouldn't help at all. This is unlikely though.

However there is a much bigger concern, which is the potential of security vulnerabilities. It is much more likely to have them in the network communication component, and they are much more dangerous there, as improper email parsing would give an attacker a possibility to send your users an email and execute code on their machine without any actions. While this may be a minor concern for home users, this would have significantly impact on the acceptance by business users and thus the goal of "hitting 1000 paying users".

Any enterprise security team would raise concerns about the security vertting of a product which is not open source (and thus not as well peer-reviewed as Thunderbird, KMail or Evolution), and is not backed by a large corporation which would have resources to conduct security testing at the level reasonable for the business product. And considering that security vulnerabilities been found in almost every piece of software, it is unlikely that mailsync doesn't have any.

from mailspring.

Same here. mailsync should be open source.
I'm reticent of using and contributing to Mailspring because of this and #33.

You're basically forcing users (most open source ones) to use your backend (a closed, proprietary one). I don't think it's a good approach.

Concerning the note in the roadmap:
If open source is a commitment, embrace it fully.
If Mailsync is hard to compile, you do it wrong. Make Mailspring and Mailsync as developer friendly as possible, for you, your colleagues and the people who wants to contribute. Otherwise the project will die. Open source is also about building a community. You can, for example, switch to Rust.
There is a lot of JavaScript, every developer know the language and have the opportunity to contribute.

I hope you'll change your mind.

from mailspring.

Is the engine libre software?
Your rationalization for making it "closed-source" doesn't make any sense from a software freedom standpoint, so I'll use the clearer term "libre software" instead of "open source".
After all, your arguments seem to be treating "open source" as a development model, rather than a licensing or ethical issue. That's the only way your points make sense. After all, Libre software:

• Isn't a commitment (or at least, doesn't have to be)
• Doesn't need support to be provided by you, you may volunteer it if you want, but no one said you have to
• Won't stop paid subscriptions
• Doesn't need to be easy to compile

All in all, you seem to be conflating the decision of license with a commitment to SUPPORT the software. No one said you had to support it though, be it responding to bugs, or even accepting PRs!

Using Wireshark or other analyses does not address the underlying ethical issue.

from mailspring.

I'm wondering how feasible it is to write a replacement (open-source) sync engine. Is there a specific/documented API that the sync engine answers to?

from mailspring.

@bengotow thank you for your answer. My question originally arose from packaging concerns: we might want to package and submit mailspring into debian at some point, and having closed-source bits is going to make it much more difficult.

from mailspring.

Same here. I'd be curious to use it, but your current build process is bonkers, dependent on the platform/libraries you built the core for (see the dirty hacks in #13), and therefore impossible to package well for many platforms.

You certainly don't have to support it though; one thing I've seen work for folks is putting up an open Github repo but disabling PRs and Issues; in effect, saying "here there be dragons" and "you're on your own" -- and if you're building from source, you need to be deft with your compiler flags.

Which makes your power users happy, makes open source possible, and if people really want a change in that repo they can either do it completely themselves or hand you a few bucks, which they might do anyway if there are a couple other beneficial features on top.

from mailspring.

I wanted to give this a try as well, however, I wanted to play with it on a raspberry pi like device, that runs on arm64. Unfortunately, without the source available, I get the following output:

Sorry, a Mailspring Mailsync build for your machine (linux-arm64) is not yet available.

As the roadmap points out, the codebase has a bus factor of one, so I don't expect this to be high priority to add more than amd64 support, but I am quite sad as the project looks quite nice.

from mailspring.

First of all, thanks for the awesome work with Nylas and now Mailspring @bengotow!
I share the same opinion of everyone in this thread... and as @barakmich exposed brilliantly there are some ways of opening the mailsync-core without the burden of maintaining an open source project (e.g. helping people to compile it and use it) and by doing so everyone stays happy. I believe that it is likely to attract even more people to Mailspring (I, for instance, am responsible for a few mail domains which have some thousands of users to whom I can't indicate Mailspring as an alternative to the webmails without knowing what is happening under the hood).

from mailspring.

Please be advised, we have renewed internal conversations about open sourcing Mailsync. (It really isn't as cut and dry as one might think...and that coming from a passionate FOSS advocate!)

We are in the process of migrating issues to Discourse, which can better facilitate discussion and discovery, and so GitHub Issues can focus on issues that are confirmed and slated for resolution in the near term. Learn more about the changes here.

We're closing and locking the issue here as part of this migration. Rest assured, this doesn't mean the issue is being discarded or ignored. Please consider joining the Discourse community and continuing the discussion there.

We hope to see you on Discourse soon!

from mailspring.

Great news everyone! Mailsync is now open source! 🎉 🎉 🎉

Read more here: https://community.getmailspring.com/t/a-free-open-source-future-for-mailspring/484

from mailspring.