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

Source code for 3.9.0 missing? #590

Closed
emou opened this issue May 14, 2019 · 44 comments
Closed

Source code for 3.9.0 missing? #590

emou opened this issue May 14, 2019 · 44 comments
Assignees

Comments

@emou
Copy link

@emou emou commented May 14, 2019

The osxfuse-3.9.0 tag shows an empty directory:
https://github.com/osxfuse/osxfuse/tree/osxfuse-3.9.0

Checking out with git also produces an empty directory.
The archives from there releases page are also empty, i.e. https://github.com/osxfuse/osxfuse/archive/osxfuse-3.9.0.zip

@bfleischer bfleischer self-assigned this May 14, 2019
@bfleischer
Copy link
Member

@bfleischer bfleischer commented May 14, 2019

That's on purpose. If you are using FUSE for macOS for a commercial software project, feel free to contact me via email. You can find my email on my GitHub page.

@bfleischer bfleischer closed this May 14, 2019
@compuguy
Copy link

@compuguy compuguy commented May 15, 2019

@bfleischer So the source code to 3.9.0 will not be released?

@bfleischer
Copy link
Member

@bfleischer bfleischer commented May 15, 2019

@compuguy For now I will not release the source code. To make a long story short, I cannot keep working on FUSE for free. I've been asking for financial support for three years, but nothing much came of it. Moving forward with FUSE is only possible if enough companies are willing to pay for the continued development. Please contact me via email, if you are using FUSE for macOS for a commercial software project.

@pmetzger
Copy link

@pmetzger pmetzger commented Jun 13, 2019

Just FYI, the result of this is that MacPorts is going to stay on the previous version and I suspect other people are going to fork it. I don't think this is a viable plan for you.

@bfleischer
Copy link
Member

@bfleischer bfleischer commented Jun 13, 2019

@pmetzger Existing versions of FUSE will work on MacOS X 10.5 to macOS 10.14. As a matter of fact, none of the versions supports macOS 10.15. Forking FUSE is certainly possible and, if you like, you can go ahead and do so. It would be great to have a second developer working on FUSE. Please keep in mind that you will need a certificate for signing the FUSE kernel extensions. Even certificate applications by well-known cloud storage providers are being rejected by Apple. As a matter of fact, MacPorts already installs the binary kernel extensions built and signed by me on Mac OS X 10.9 and above. How is that different from the current situation?

That being said, I would prefer to release the source code. But I need funding and I won't get any if the FUSE source code is available for free, even for commercial use. I have talked to many companies but without much success. Do you have a better suggestion for solving this dilemma?

@pmetzger
Copy link

@pmetzger pmetzger commented Jun 13, 2019

Please keep in mind that you will need a certificate for signing the FUSE kernel extensions

And? That's hardly a big deal. I've been paying for a "real" developer account for many years now. It's not an impediment. MacPorts could get such a thing itself for the organization; it has friends at Apple. But I will have to think about how much I care about this. It might be easier to simply stop using the tool entirely.

Do you have a better suggestion for solving this dilemma?

You might not be able to solve it, but alienating your potential supporters could very well make it impossible to make any progress, as well as hurting your own reputation. There are no guarantees that any path will get you enough money to work on this, of course. However, some methods are pretty much guaranteed to sabotage your efforts. I would say that the current path is one of them. People get very irritable about such things. There are more and less appropriate ways to get people to pay attention to you; this is not one of the more appropriate ones.

@bfleischer
Copy link
Member

@bfleischer bfleischer commented Jun 13, 2019

And? That's hardly a big deal.

Try applying for a kernel extension singing certificate. That's not the standard Developer ID certificate every registered developer gets. Then when you maintained a project like FUSE for macOS alone for eight years we may talk again. Have you ever written a single line of kernel code or debugged a massively parallel file system? Trust me, that's a big deal.

If you chose to stop distributing FUSE for macOS and thereby all FUSE-based file systems through MacPorts, that's your decision and I respect it. I won't patronize you for it, like you are doing here. Luckily there are alternatives, Homebrew distributes the latest version of FUSE for macOS.

You might not be able to solve it, but alienating your potential supporters could very well make it impossible to make any progress, as well as hurting your own reputation.

Let me worry about my reputation. There were two alternatives: Raise funds to continue working on FUSE or abandon the project. I believe the option I chose is the better one. Don't you?

@compuguy
Copy link

@compuguy compuguy commented Jun 13, 2019

@bfleischer At a minimum, the fact that osxfuse is no longer open source (nor will the source code be provided) should be notated in the README.md.

@pmetzger
Copy link

@pmetzger pmetzger commented Jun 16, 2019

Have you ever written a single line of kernel code

Yes. I've written a ton of kernel code. But this is irrelevant — it's an ad hominem. It makes no difference to my argument if I've never written a line of any sort of code.

Oh, and let me note that ad hominem attacks only make it much less likely that you will ever get what you want. Who would want to raise money to help someone who insults people?

If I decide osxfuse is important enough to me, I will work on finding another maintainer.

@bfleischer
Copy link
Member

@bfleischer bfleischer commented Jun 16, 2019

I've been asking for pretty much any form of support for years. FUSE needs a lot of work to get where it should be. Many parts of the code are old and need to be rewritten to add support for new features or getting rid of performance bottlenecks. Most parts of the FUSE kernel extension are more than a decade old. We still don't have libfuse 3 support for macOS. The Objective-C framework does not even use ARC, protocols, or blocks. It's still based on the Objective-C 1.0 runtime. The VFS plugin still uses exclusive locks instead of read-write locks. The list goes on and on.

This is simply too much work for one person in addition to a full-time job. In other words, I either need to find more time to work on FUSE or more developers need to join me in working on FUSE for macOS. This is exactly what I've been asking for for years. I did not stop releasing the source code because I'm greedy. I did it because nothing else I tried over the years to get the necessary attention worked. That's why I asked if you could suggest another path. Continuing like the years before does no longer work.

Reputation is not important. I stand behind my actions. And I will explain my reasons to everyone who asks. All I care about it that FUSE on macOS lives on. And I will do everything I can to ensure this. That's what I've been working on all these years.

@pmetzger I never insulted anyone. At least that has never been my intention. However, you never asked for my reasons for stopping to release the source code, but attacked me from the start. You are telling others I might take FUSE offline in a fit of pique (macports/macports-ports#4601) without ever having spoken a word to me. Then you continue by belittling what I have been working on for years and talk down to me. This is the very definition of being impolite and hostile.

By the way, asking you if you have ever written a line of kernel code is not irrelevant. Many people think developing a kernel extension is not that much different form writing a simple app. Someone who has written kernel code knows that it is a whole different story.

@vgough
Copy link

@vgough vgough commented Jun 17, 2019

Certainly this change of status warrants a mention in the README? I came here to diagnose an error, only to be very confused that the source here does not match what is installed. I don't have an opinion at the moment on what development model is best, but I find it disturbing that the source / licensing status isn't mentioned at all. If you're looking for support, it would also help to mention the form of support you'd like in the README.

@pmetzger
Copy link

@pmetzger pmetzger commented Jun 18, 2019

This is simply too much work for one person in addition to a full-time job

Then drop it and let someone else maintain it.

@compuguy
Copy link

@compuguy compuguy commented Jun 25, 2019

Do you have a Patreon account (or with an equivalent service)? I'm sure there are users out there that would like to contribute to the continuing development of osxfuse @bfleischer.

@bfleischer
Copy link
Member

@bfleischer bfleischer commented Jul 2, 2019

Patreon and similar crowdfunding services do not work for me. It's complicated and I don't want to bore you with the details. There are some tax-related issues in Germany. If Plus3 IT would like to support my work, there is no need to go through Patreon, simply contact me by email.

@pmetzger
Copy link

@pmetzger pmetzger commented Jul 3, 2019

So you're upset that no one is supporting you, but you've provided no obvious way for normal people to support you? And it's "complicated" why you can't use a crowdfunding site?

@bfleischer
Copy link
Member

@bfleischer bfleischer commented Jul 3, 2019

@pmetzger I've never complained about normal people not supporting the project and I will never ask end users for financial support. FUSE will always be free. However, what I'm asking for is for companies, that are selling FUSE-based products or rebrand FUSE and bundle it with their apps, to re-invest some of the profits in the continued development of FUSE on macOS, if they can afford it. I don't think that is unreasonable.

@compuguy
Copy link

@compuguy compuguy commented Jul 3, 2019

When I asked you @bfleischer if you had a Patreon (or Ko-fi, etc), I was speaking for myself, not my current employer (my current employer doesn't sell or bundle osxfuse). I am just an end user of osxfuse.

@pmetzger
Copy link

@pmetzger pmetzger commented Jul 3, 2019

However, what I'm asking for is for companies, that are selling FUSE-based products or rebrand FUSE and bundle it with their apps, to re-invest some of the profits in the continued development of FUSE on macOS, if they can afford it.

How would any of them even know how to do that if they're unaware you want help and provide no mechanism by which they can help you? (If you are providing such a mechanism, it's well enough hidden not to be obvious even if someone is deliberately looking for it.)

@fulldecent
Copy link

@fulldecent fulldecent commented Dec 11, 2019

Yup, it perfectly reasonable for the maintainer to continue development and release only binaries. License allows it and that good.

As an end user I generally prefer open source software so this is a loss for me. And I know maintaining projects is hard, it would be nice if this could be released dual-license to restrict commercial use but then also include a community funding approach. Maybe GitHub Sponsors is an option.

@joshlawrence
Copy link

@joshlawrence joshlawrence commented Dec 11, 2019

Then drop it and let someone else maintain it.

@pmetzger or fork it and do it yourself?

@patmoore
Copy link

@patmoore patmoore commented Dec 11, 2019

@bfleischer I agree with your move. Purists don't seem to understand banks accept only euros, dollars, pounds, yen, etc.

2 suggestions:

  1. you put the source into some sort of escrow service. So in the event of death, or ?, your work can continue to be built on once you are beyond cares.
  2. consider creating coursework/book (for $$ of course) based on your learnings from writing osxfuse.

The coursework is a way to:

  1. monetize osxfuse learnings from individual developers.
  2. shows how difficult the subject matter is.
  3. spreads knowledge
  4. enables developers to argue to management that they should just pay up rather than "build it ourselves"

And yes I would be willing to pay - not because I want to write device drivers but simply because I like understanding complex threading issues.

I know how difficult it would be to write the courses yourself - maybe a professor /TA at a local university would help?

I wish there was more ways that OS developers could monetize. Remember the issue around the lack of OpenSSH funding?

@patmoore
Copy link

@patmoore patmoore commented Dec 11, 2019

@bfleischer

However, what I'm asking for is for companies, that are selling FUSE-based products or rebrand FUSE and bundle it with their apps, to re-invest some of the profits in the continued development of FUSE on macOS, if they can afford it

You shouldn't "ask" here. Irregardless of "profit", if a commercial entity is using your work, they should expect to pay for it. A business expects to pay for all the other components that goes into the product they build. osxfuse is just another component in the BOM.

@GabrielRavier
Copy link

@GabrielRavier GabrielRavier commented Dec 17, 2019

Why can't a model similar to the one Qt uses be adopted here ? (that is, having the source be available, while still requiring payment for use in commercial products)

If adopting such a model is possible, why not do it ?

@pmetzger
Copy link

@pmetzger pmetzger commented Dec 17, 2019

Qt doesn't require payment for use in commercial products. It's LGPLed. Oh, and I see no reason that commercial entities should have to expect to pay to use open source programs either — the word you are looking for when you expect someone to pay is "proprietary license". People don't routinely pay for Linux, or GCC, or dozens of other things that involve vastly more work than a FUSE implementation.

@bfleischer
Copy link
Member

@bfleischer bfleischer commented Dec 17, 2019

@pmetzger One difference between GCC, Linux and FUSE for macOS (besides the complexity) is most likely the number of active contributors working on each project. Some Linux developers are full-time employees who are being paid for their work on Linux.

@pmetzger
Copy link

@pmetzger pmetzger commented Dec 18, 2019

So what? If you are making something open source, the expectation is that people can use it without paying you, and that they in fact will use it without paying you. Getting upset about that is churlish. If you want to insist that people pay you, then don't work on open source.

@GabrielRavier
Copy link

@GabrielRavier GabrielRavier commented Dec 18, 2019

If the license forbids you from doing something (such as using the project commercially (non-commercial use clause)) or forces you to make your own project open source in order to link to the one the license applies to (copyleft like the AGPL), then that's a legal requirement. Violating that requirement would be breaking the law (in which case the lawbreakers would be easily prosecutable).

Making the project open-source wouldn't really facilitate people illegally using bfleischer's software (considering they could just get it off Homebrew), in fact it would probably get him support from people who really don't like companies infringing on the license of open source projects.

@bfleischer
Copy link
Member

@bfleischer bfleischer commented Dec 18, 2019

If you are making something open source, the expectation is that people can use it without paying you, and that they in fact will use it without paying you.

That's true, but my hope was that enough companies would support the project's continued development or that the project would attract more regular contributors. Eight years later I came to the conclusion, that this did not work out.

If you want to insist that people pay you, then don't work on open source.

That's exactly what I did.

@pmetzger
Copy link

@pmetzger pmetzger commented Dec 18, 2019

That's true, but my hope was that enough companies would support the project's continued development or that the project would attract more regular contributors. Eight years later I came to the conclusion, that this did not work out.

Let me repeat: IF YOU DO NOT TELL PEOPLE YOU NEED HELP, NO ONE IS KNOW YOU WANT ANY.

@bfleischer
Copy link
Member

@bfleischer bfleischer commented Dec 18, 2019

@SpamControl
Copy link

@SpamControl SpamControl commented Dec 19, 2019

@pmetzger

People don't routinely pay for Linux, or GCC, or dozens of other things that involve vastly more work than a FUSE implementation.

This is a straw man argument. No one argued that these product were not free to use. The reason the author decided to closed its source is to be able to fund himself for working on it.

If you are making something open source, the expectation is that people can use it without paying you, and that they in fact will use it without paying you.

That is simply not true. Take a look at RedHat Enterprise or Gitlab's platform. Those projects are open-source but the companies are still trying to make people pay for their product.

Let me repeat: IF YOU DO NOT TELL PEOPLE YOU NEED HELP, NO ONE IS KNOW YOU WANT ANY.

Stop your unbased frustration against the author. I agree that the author could have been more transparent about the issue, and about the transition to closed-source. However, nothing prevents you from forking the last commit (which you already did) and maintain it yourself, and finding other people helping you do so.

@pmetzger
Copy link

@pmetzger pmetzger commented Dec 19, 2019

Take a look at RedHat Enterprise or Gitlab's platform.

In the one case, RedHat charges for support, not the code. You can run something identical (Centos) for no cost. In the case of Gitlab, you can use the open source version for free; if you want closed source features you pay for those.

Stop your unbased frustration against the author

How about I do what I want, and you do what you want, and we accept that we both have a right to whatever opinions we wish?

@feross
Copy link

@feross feross commented Dec 26, 2019

@pmetzger You are not entitled to free labor from others under the terms that you dictate. If you don't help to maintain this project then you don't get a seat at the table when making decisions. Please stop whining.

@pmetzger
Copy link

@pmetzger pmetzger commented Jan 1, 2020

@feross I think the person who is whining is the author.

@bfleischer
Copy link
Member

@bfleischer bfleischer commented Jan 2, 2020

I think the person who is whining is the author.

@pmetzger I explained my reasons for stopping to release the source code and the recent license change. I have changed the terms, but I did not stop maintaining FUSE for macOS or releasing updates. Did you contribute to the FUSE for macOS project other than expressing your opinion repeatedly? We must have have different definitions of whining. I think it is time for you to move on.

@GabrielRavier
Copy link

@GabrielRavier GabrielRavier commented Jan 2, 2020

@bfleischer I still would hope that you understand that you can release the code without making the project free for commercial use. You could make the code public, while using a license that would restrict people from freely using the project for commercial use. Then, there would be no difference with the situation in which you don't release the code (if they wanted to go into illegality they'd just use the release binaries you said yourself were on Homebrew) except that people would be able to inspect your code and contribute to it.

@pmetzger
Copy link

@pmetzger pmetzger commented Jan 3, 2020

Did you contribute to the FUSE for macOS project other than expressing your opinion repeatedly?

As I've said, if I decide at this point that I care enough about the continued existence of FUSE for the platform, I'll fork it. At the moment, I simply not sufficiently interested. Should that change, I will not be "contributing" to this effort, which is not open source, I'll simply fork it and avoid having further contact with the existing contributors.

I've done this in the past, by the way. I forked and maintained Growl for a while after its developers decided to make it closed source, though after the built-in MacOS notifications framework became robust I dropped it because no one cared any more.

@develth
Copy link

@develth develth commented Feb 21, 2020

Fleischer Vs. Metzger

If you're German it's a funny battle 😂

@paaguti
Copy link

@paaguti paaguti commented Feb 22, 2020

@chrisbehanna
Copy link

@chrisbehanna chrisbehanna commented Feb 25, 2020

Take a look at RedHat Enterprise or Gitlab's platform.

In the one case, RedHat charges for support, not the code. You can run something identical (Centos) for no cost. In the case of Gitlab, you can use the open source version for free; if you want closed source features you pay for those.

The latter case is also true for RedHat. If you want the super-gee-whiz-bang management tools for integrating with OpenLDAP/Active Directory, you have to pay for them. Ditto for live migration support for VMs.

I've been a huge fan of osxfuse for many years, as an end-user. @bfleischer, I'm not flush with cash right now, but I'd be happy to toss something in a tip jar somewhere when I'm able, if you can arrange for such to exist.

@paaguti
Copy link

@paaguti paaguti commented Feb 26, 2020

@FranklinYu
Copy link

@FranklinYu FranklinYu commented Apr 22, 2020

You could make the code public, while using a license that would restrict people from freely using the project for commercial use.

I’d like to support this argument: License Zero is designed exactly for that purpose. Removing the source-code isn’t necessary at all for the goal of raising funds.

I’m personally fine with the decision of making it non-open-source; I only mean that there might be a way to serve the goal better, like raising more funds, or raising them more sustainably. This could help Benjamin in the long run.

markmentovai added a commit to markmentovai/macports-ports that referenced this issue Oct 22, 2020
The Portfile for wimlib was broken: it specified port:ntfs-3g and
port:osxfuse in depends_lib, but did not actually use either.
configure.args contained --without-fuse, and while it seems to have
intended to enable NTFS support, it did so by specifying --with-ntgs-3g,
a typo that prevented NTFS support from being enabled. Meanwhile,
because of the sorry state of osxfuse, the port was difficult to install
on some systems (osxfuse/osxfuse#590,
macports#4601), rendering this
port essentially unusable simply because it specified osxfuse as a
dependency, but did not use it.

This introduces +fuse and +ntfs variants. +ntfs must be a variant too,
because ntfs-3g depends on osxfuse. Because the previous revision of the
Portfile did not properly enable either fuse or ntfs-3g support, neither
of these variants are selected by default. This assures maximum
compatibility with all macOS systems without any loss of functionality
relative to the previous revision of this port.
markmentovai added a commit to markmentovai/macports-ports that referenced this issue Oct 22, 2020
The Portfile for wimlib was broken: it specified port:ntfs-3g and
port:osxfuse in depends_lib, but did not actually use either.
configure.args contained --without-fuse, and while it seems to have
intended to enable NTFS support, it did so by specifying --with-ntgs-3g,
a typo that prevented NTFS support from being enabled. Meanwhile,
because of the sorry state of osxfuse, the port was difficult to install
on some systems (osxfuse/osxfuse#590,
macports#4601), rendering this
port essentially unusable simply because it specified osxfuse as a
dependency, but did not use it.

This introduces +fuse and +ntfs variants. +ntfs must be a variant too,
because ntfs-3g depends on osxfuse. Because the previous revision of the
Portfile did not properly enable either fuse or ntfs-3g support, neither
of these variants are selected by default. This assures maximum
compatibility with all macOS systems without any loss of functionality
relative to the previous revision of this port.
ryandesign pushed a commit to macports/macports-ports that referenced this issue Oct 28, 2020
The Portfile for wimlib was broken: it specified port:ntfs-3g and
port:osxfuse in depends_lib, but did not actually use either.
configure.args contained --without-fuse, and while it seems to have
intended to enable NTFS support, it did so by specifying --with-ntgs-3g,
a typo that prevented NTFS support from being enabled. Meanwhile,
because of the sorry state of osxfuse, the port was difficult to install
on some systems (osxfuse/osxfuse#590,
#4601), rendering this
port essentially unusable simply because it specified osxfuse as a
dependency, but did not use it.

This introduces an +ntfs variant. Because the previous revision of the
Portfile did not properly enable ntfs-3g support, this variant is not
selected by default. This assures maximum compatibility with all macOS
systems without any loss of functionality relative to the previous
revision of this port.
@guycalledseven
Copy link

@guycalledseven guycalledseven commented Nov 23, 2020

As an avid user of osxfuse/fuse, after reading this depressing thread, I am gonna reference issue #742 here for future reader to see that currently there are possibilities for this project to get proper funding:

...opportunity for Facebook to sponsor the continued development of FUSE on macOS...

@luckydonald
Copy link

@luckydonald luckydonald commented Sep 8, 2021

did it work out yet?

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

Successfully merging a pull request may close this issue.

None yet