For those questioning the FOSS-ness of Scarf. Start with Wikipedia, then read a few more things for background.
Scarf itself is BSD3 licensed. You can do whatever you want with it. Even fork it and remove all the things it was designed to do.
There is nothing not-FOSS about this project. The goal (and I'm not affiliated with it in any way, nor do I know the author) is to support FOSS developers. If you're a FOSS developer, you want that, right? And if you're not, do you know how at risk you are because FOSS devs are not compensated consistently and well? That's the message we need to get out. Projects like Scarf are important, and this is a new space, because we need to raise awarenes about this issue and solve it.
Will there be bad actors? You bet. Are there already bad actors? You bet. It's not about creating a perfect solution, but creating a better solution than what we have now. Which means creating any solution at all for this particular problem at this point in history.
For every project that acknowledges and addresses this problem, I applaud you. We need stepping stones.
It's not the worst solution, either (not saying it's super great, mind you). For the developer, BTC has no server to sysadmin (btc miners are somebody else's problem). If you're a developer that's not in/near the US financial system, it can be very difficult to get paid (eg developer in the country of Georgia, Estonia, North Korea) (Never mind the legal/moral/political question, everyone want to get paid.)
"Scarf de-risks your product by helping you pay a small monthly amount to ensure that your open source dependencies remain alive and healthy."
"Platform to help open source developers monetize their work."
A lot of companies want two things: open source and a way to pay for software. Sometimes this is even the reason to use SaaS, because it is easy to pay for.
And a user point of view is that my usage data is now a bargaining chip to be used by an intermediary between me and a developer I think made a decent stab at a library I need.
I'm sorry I'm really failing to see any benefit for anyone in the deal apart from the middle man who will invariabley scrape all the usage stats and sell it
From a user point of view, you have a way to contribute to the developers that give you free stuff without having to do anything additional. Because the developer gets anonymized usage statistics, this will ultimately mean higher quality software for the users.
But whereas "auto-magic" is a good characteristic in software, it's kind of off-putting in financial matters.
As far as the software goes, if it "just works", that's great. When it comes to the money, I don't want to know if it "just works". Within 2 minutes of arriving at the Scarf site, I want to know how much goes in one end, how much comes out the other end, how to set and change the prices, and how much (if any) leaks to the Scarf service. I'd like to know this by the second paragraph of the first page. Having skimmed the site, I still have no idea.
However, please correct me if I'm wrong but is this truly open source. If the developer intends to open-source his software then in-app purchases defeat the entire purpose?
Also, if the developer does want to release his software with the intent to make money, he can simply release a premium version with the added features.
I don't want to sound very harsh but as an open-source developer, this kinda defeats the ethics of what open-source software truly is.
Would love to hear alternative views...
Free and Open Source and making money are separate issues. This is the Free as in Beer, versus Free as in Freedom bit. FOSS is not like Beer. It is free of constraints in what a user can do with it, including changing it if it is also Open Source.
Not enough people are aware of it, I think SaaS vendors need to be clear about this. I would hope that we'll see more "software payment" notions instead of just often listing "setup fee" which just reinforces the misnomer that Free is about the absence of monetary gain.
It would be cool to see popular packages on the front page. Otherwise it looks like there are zero.
Also, searching then searching again messes with back navigation.
* My user chooses to install my package with scarf, either because I force them to (by not making it easily available elsewhere) or because they want to support me (yay!)
* I make money from their install, and/or their use of the package (is this correct?)
In that case, as Mallory, as a bad actor, I:
* Want to make a package that looks affordable but pulls in dependencies
* I want to make those dependencies cheap at first, but then I'm going to make them expensive later, when you are, well, dependent (ahem)
* I want those deps to be, as much as possible, me and my friends
I'm not even going to get into the abuse potential I can imagine would obtain by preying on naive good actors; e.g. convincing some well-intentioned dev to use my dep and then effectively taking rents from all of their downstream users.
I haven't had a chance to play with Scarf yet but I'd love to hear about how you handle scenarios like this on its website. Because I'm pretty sure these scenarios are why something like scarf hasn't shown up before.
(Personal belief/stance informing this worry: FOSS got big by providing easily-reasoned-about costing structure in an industry that had hitherto been beholden to things like on-site auditors, per-seat licensing, hidden costs, submarine patents, etc; our value prop was "you always know your cost is gonna be $0, plus installer and maintainer salaries", which is much better than "We decided this now costs double". We didn't so much cost less as cost predictably.)
It could be install, usage, usage without sending analytics, and eventually other tiers too!
The idea of the system being abused is a great point to bring up. There are a few ideas floating but it isn't fully nailed down yet because the project is still in very early stages :). We'll certainly get there.
Cost predicability is something I had not thought of, I agree that's a compelling use case for FOSS. I'll think about that moving forward and how Scarf can help bring revenue to developers while keeping costs predictable for users.
Not even bringing Mallory in. Just the ordinary use case of "Hi, my app is free or pay... and dep #1 is free or pay and dep #2 is free or pay and dep #3 is free or pay so now you have some choices."
How are you guys thinking about Github's new package registry?
Scarf could in theory install packages directly from the registry, but I haven't looked into it much.
- Free: metrics get sent to the scarf service
- Paid: no metrics get sent to the scarf service
Is that correct?
Also, even if you want to release proprietary software, writing payment integrations is still a lot of work and Scarf makes this much easier. You can put proprietary, compiled binaries on the platform too
a) more likely to contribute code (since they have it), so fine with me! b) much less likely to be using it at an enterprise, which is the main target
> [captured data] Sub-commands and flags that are passed on the command line
So it's parsing the command line which can have environment variables with passwords. eg `foo run -e CONTAINER_PASSWORD=""`
This isn't implemented yet but Scarf will batch up the telemetry metrics calls so it won't actually be sending 100's of requests in that case.
> So it's parsing the command line which can have environment variables with passwords. eg `foo run -e CONTAINER_PASSWORD=""`
Yes, but the actual arguments to those flags are not sent to Scarf, so in this example it would only send "run", "-e", and "CONTAINER_PASSWORD". It's straightforward to also detect things like url's, file paths, certificates, and other sensitive data, so that's not sent either. All of the CLI code is open source (https://github.com/aviaviavi/scarf) so there is full transparency to what data is captured and sent.
Thanks for the feedback.
EDIT: should be fixed!