Live data from Hacker News

FUSE for macOS is no longer open source

colatkinson.site

181–190 of 407 posts

Re: FUSE for macOS is no longer open source

#181
post #95

this quite reminds of the openssl saga, but on a smaller scale, with single developer more or less responsible for world's encryption for decade. it's a pity, it's a shame that companies who use FOSS benefit, but do not understand (or do, but ignore) the idea of FOSS, which is to give back to community. this also includes other FOSS companies, etc as everyone uses openssl, zlib and sqlite. to base a project on FOSS r…

> to base a project on FOSS requires that you contribute back

No, it absolutely does not. If that was a requirement, it should say so in the license.

If you don't want your work to be publicly usable by people who don't contribute, don't open source it.

Re: FUSE for macOS is no longer open source

#182
post #176

Earlier quoted context omitted.

But every person, sensible or not, has bills to pay. When you say "no sensible person goes into FOSS for the money" you are saying "most people can't afford to actively maintain a FOSS project", and you really can't claim that is in any way good for FOSS.

"Most people can't afford to actively maintain a FOSS project" has always been true. It has been a hobby for some, a privilege allowed by the workplaces of others, and in a few rare cases companies have been built that charge for consulting and manage to fund a distro or other project that way. Or dual-license tech like Trolltech.

Yes, and I am saying that is not a great thing for FOSS.

Re: FUSE for macOS is no longer open source

#183
post #151

Earlier quoted context omitted.

But every person, sensible or not, has bills to pay. When you say "no sensible person goes into FOSS for the money" you are saying "most people can't afford to actively maintain a FOSS project", and you really can't claim that is in any way good for FOSS.

That doesn't sound like much of a change from the last 30 years. FOSS has done fine so far. Really the only thing that might work is if there was broad community acceptance of not changing all the lower parts of the software stack all the time so the maintenance burden is lower. Honestly; if we were interested in what was good for FOSS all that needs to happen is that hardware stops improving all the time. Then every…

I'm not sure the argument "FOSS has done fine so far" is that convincing when you then lay out many of the places where FOSS has been failing miserably.

Re: FUSE for macOS is no longer open source

#184
post #84

Earlier quoted context omitted.

No, this wouldn't have been a problem if the software had been gpl licensed, as the companies would've been forced to give back whatever they changed themselfes, potentially helping him out a lot

If it were GPL-licensed, they'd have to give back the whole Happy meal, not just the FUSE fries. Perhaps you're thinking about LGPL, or a linking exception of some kind? Alternatively, he totally could have gone and dual-licensed GPL and a permissive commercial license as a monetization strategy, like the author pointed out.

[deleted]

Re: FUSE for macOS is no longer open source

#185
post #170

Earlier quoted context omitted.

Maybe. What we know factually at this point in time: osxfuse was BSD licensed, Google used it and haven't contributed back. osxfuse is popular project. If it was GPL licensed, do you think Google would bother to use it? Or would they write their own instead? Would we even know about osxfuse then? MIT/BSD is amazing on bootstrap phase, when getting code used and building user base is top priority. Monetization always…

MIT/BSD is in a kill free software phase, where commercialization of SAAS and other services are king. MIT/BSD is turning open source software, in to open source dev tools and libraries, no longer is should the end user software be free and open, no just the tools, frameworks, languages, and libraries used to create the end user software I would not call this trend "amazing"

This trend means open source is working as it was designed to.

Re: FUSE for macOS is no longer open source

#186
post #98

Earlier quoted context omitted.

Donations don't allow for a sustainable business.

But they demonstrably can allow for a sustainable project , the obvious example being the Linux Foundation. And if you admit to the existence of donations, then do you admit that you were wrong to say "open source folks don't want to pay for anything"?

Since you brought up the Linux Foundation as an example, the large pool of contributions are from Fortune 500 happy to use Linux instead of paying for UNIX licenses.

Which in any case only a tiny part of kernel contributors can live from.

Re: FUSE for macOS is no longer open source

#187
post #151

Earlier quoted context omitted.

But every person, sensible or not, has bills to pay. When you say "no sensible person goes into FOSS for the money" you are saying "most people can't afford to actively maintain a FOSS project", and you really can't claim that is in any way good for FOSS.

That doesn't sound like much of a change from the last 30 years. FOSS has done fine so far. Really the only thing that might work is if there was broad community acceptance of not changing all the lower parts of the software stack all the time so the maintenance burden is lower. Honestly; if we were interested in what was good for FOSS all that needs to happen is that hardware stops improving all the time. Then every…

Really fine, maybe next year we get the FOSS desktop.

Re: FUSE for macOS is no longer open source

#188
That was a very good write-up. Quite fair, and Kool-Aid-free.

It is a pretty good synopsis of the issues faced by open-source developers, these days.

Much like The September That Never Ended was probably the best thing that ever happened to the Internet, but was really tough on the folks already there, the adoption of open-source systems by commercial entities is making open-source "sexy."

Open-source developers (of which I'm one) need to make extra efforts to document and "decorate" their projects, and often dream of "going viral."

However, like so many folks have found on YouTube, fame != money.

In fact, once your project starts getting all that lovely adoption and enthusiasm, it will also start getting demanding, pithy, threatening and abusive contacts from users.

I strongly suspect that a lot of OS developers have walked away from promising projects because of this crap. I'm a stubborn, cantankerous bastard, so I haven't; but I also have the "advantage" of not having any projects that have gone massively viral. It's been a drip that I can use a saucepan to catch; not a deluge.

This smells like a business opportunity. Maybe set up a service for OS developers that will field all the abuse for them, and make it real cheap.

Re: FUSE for macOS is no longer open source

#189
post #172
post #97

Earlier quoted context omitted.

GDrive Enterprise is a publicly available product with a Mac client so the footnote doesn't seem to line up with what you're saying.

I wasn't aware that osxfuse is distributed by Google. If that is the case then I am sorry for spreading false information and indeed, the GPL would apply.

It's still not clear whether the GPL would apply in the way commenters here think it would.

GPL clauses would only affect Google code upon linking. It's often possible to use fuse style software without linking - they could use it via the command-line and mount whatever they need at startup or even dynamically.

Does osxfuse have a command line tool? Most fuse style software does. If it doesn't, Google could have written a command-line client and open sourced just that.

Re: FUSE for macOS is no longer open source

#190
This is a very sucky situation to be in, and I've been on both sides of it.

I wrote KSCrash [1] a decade ago, and it's become the de-facto standard for crash handling in the Apple ecosystem. I didn't intend for this to happen; I just wanted crash handling MY way. But it's my baby, and I need to support it (technically no, but yes I do), even though I get no financial benefit from it. For a year, I was paid by a private company to supercharge it, but that funding dried up, and as a result the Android port stalled because I took a new job to pay the bills, writing Java code.

Musashi [2] is a smaller example. It's an emulator, so it doesn't need nearly as much attention. All the same, a number of 68k based anthology releases for popular game systems used it and contributed neither fixes nor funds. I don't mind so much with this one because, as I said, it's pretty low maintenance.

Today, my latest itch is efficient and human-accessible data communications, and so I'm spearheading a new bidirectional, general-purpose, platform agnostic, encryption-capable, transport-agnostic RPC protocol [3], including all of the supporting technology it requires [4] [5] [6] [7] [8] [9]. If it takes off, it will save the entire planet a TON of time, energy, and cost, and I'll probably not see any donations or thanks from those who benefit the most.

Please don't take this as complaining. I'm still going to develop and support my babies, because I'm not doing this for the money; I'm doing it to better the state of computing systems (mostly for my own sanity). However, because I'm forced to find separate employment to support my family, it leaves me with FAR less time to focus on these technologies. My estimate would be that I'm running at 1/4 my usual velocity when I require separate employment. For bigger projects that turns a 1 year project into 4 years.

However, from a company perspective I also understand. Giving donations is actually a big pain in the ass, especially if it's to a foreign entity. Normal invoices are FAR easier, but then how do you structure it for free access + payment options without pissing people off? It's a tricky situation...

[1] https://github.com/kstenerud/KSCrash

[2] https://github.com/kstenerud/Musashi

[3] https://github.com/kstenerud/streamux

[4] https://github.com/kstenerud/concise-encoding

[5] https://github.com/kstenerud/compact-float

[6] https://github.com/kstenerud/compact-time

[7] https://github.com/kstenerud/varpad

[8] https://github.com/kstenerud/variable-bit-padding

[9] https://github.com/kstenerud/vlq

Post reply on HN