I replied to a few comments, and will post my own now.
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.
A customer who wants to get money to a FOSS developer, is hard enough for developers to manage. (One success of the Apple store is that it makes getting paid easy and is easily worth the cut off the top that they take.) The current state of the art is to drop a bitcoin address in the `Readme.md` and then customers just need to pay with bitcoin. Which to be real, is too high a bar for many a customer).
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.)
That's a good point about this not helping people who aren't near the US financial system, for now. I'm planning a feature for developers to be able to connect a crypto wallet that they could be payed out to. Package users could optionally pay with a cryptocurrency, or just with a credit card like you can now. The package developers should not need to deal with complexity like this.
Very well stated :). Scarf is still very early on and not remotely perfect. But I hope that people will give it a try, we can iterate and iterate and see if we can get more towards an open source model that works better for everyone.
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.
So from a developer point of view the more popular your package is financially the less insight into its use you get?
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 developer view, you now don't have to give away your usage data just because you give away your software for free. You have more leverage to ask companies and commercial entities to pay for your software, while letting individuals use it for free.
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.
I like the idea; if someone wants to make some money off of customers who are more willing to pay than to make efforts to avoid paying, it's nice to have an easy way to do that.
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.
This is useful feedback, thank you. There's definitely still a lack of documentation, and I'm working to improve that. Currently, Scarf takes fees only to cover the Stripe fees, it doesn't add any additional fees in an effort to encourage people to give it a try. Scarf will eventually take its own transaction fees but that exact amount isn't ironed out yet. I'll add this to the FAQ
I understand where this is coming from, and it's definitely from a good place, but honestly I think the solution is a bit naive.
Developers are not going to be able to sustain themselves by simply having their software connected to a package manager that charges them when they install a package. You might as well just sell proprietary software at that point.
We as a community need to be look at solutions like Tidelift [1] that will draw in real, serious and interested ENTERPRISE customers. That is where the revenue will come from and that it what will make it viable enough as a long term solution for both the developers AND consumers of FOSS.
Note: I am in now way affialiated with tidelift other than thinking they are smart dudes who are approaching this very pressing issue correctly.
[1] https://tidelift.com/
Scarf also aims to help developers sell open source software to enterprises. The idea of leveraging telemetry by default in exchange for payments specifically targets companies, who can certainly pay for that use case. An issue with Tidelift is that it's more for libraries, but CLI tools are not necessarily included in your project's manifest that Tidelift would see. Tidelift and Scarf can both help open source devs from different angles.
I like the idea of Scarf allot. This solves a very good problem of getting analytics on features that get released. And these insights would certainly help improve the software.
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.
Great question. So I think this still is in the spirit of open source, because you can bypass scarf completely by just installing the package from source if you want to. For my own packages that are hosted on Scarf, I'm totally happy if someone chooses to do that, because then they're more likely to contribute code back to my projects, which is great. Scarf just gives devs a way to makes the path of least resistance for users a path that results in either usage analytics, money, or both. I hope that makes open source a more sustainable endeavor for the developers.
There is no need to bypass Scarf to align completely with FOSS principles. If Scarf is not encrypting the source, adding new license constraints, or hiding it in any way, when it adds its wrapper.
> If the developer intends to open-source his software then in-app purchases defeat the entire purpose?
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.
Open Source and SaaS are not mutually exclusive. If a SaaS product is also FOSS, it just means that more than one vendor could provide the same exact service. You're paying them for their services and physical resources. Every cloud/hosting provider does this, offering Linux, Apache, etc. And, yes, they can even charge you for the software.
> And, yes, they can even charge you for the software.
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.
I haven't tried this yet, but poking around the site, I'm wondering what mitigations you have for potential abuse? I'm concerned specifically about transparency to the end user about the costs of the packages that they've installed.
Thinking aloud:
* 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.)
> I make money from their install, and/or their use of the package (is this correct?)
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.
I can't imagine using a package on this system as a dependency at all.
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."
From the user's perspective, the price of the dependencies will need to be baked into the price of the package, the user should not need to deal with that. The developers shouldn't deal with it much either, really. Scarf can handle making sure dependencies are paid appropriately based on prices agreed to by developers.
nice work! I have a similar project https://ligit.dev we took the approach of letting the developer do everything as they usually would except for the license.
How are you guys thinking about Github's new package registry?
Yup, that's the current model! But Scarf can support much more flexibility, so ultimately the developer will have a variety of options. A package could be fully free, and payment through Scarf would be more of a donation. It even could be fully paid, and a user would have to purchase the ability to install or use the package at all. Leveraging metric collection to ask for payments like this seemed like a good thing to start with, so certainly curious for any feedback there.
If the software is open-source, it will just get forked in a branch that removes usage metric uploading. If you want to make money with software, just release proprietary software, not sure what's so difficult about this.
Because dealing with proprietary software is a pain in the ass. Have you ever written code for a prop operating system that required a prop compiler and a prop framework? It was impossible to do anything other than begging the owner to write a better documentation or fix their bugs. Today, I just open up the source code of whatever package I'm using and supplement the doc with the code itself. Open source makes software tolerable.
Uploading your package to scarf does not impact your code at all, all the payments and analytics is at the packaging and distribution level.
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
Interesting that the three sibling replies here at present completely miss the point. Vortico is saying that nobody can make money this way as an OSS author/developer because someone else will just fork your code and release it sans payment mechanism. Or perhaps even with them as the payment beneficiary rather than you.
Right, I was addressing the fact that forking isn't even necessary here. It's true people can always go get the source if they want to use it for free. But someone just bypassing Scarf to use the source code directly makes them:
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
This reminds of the internet explorer toolbars which counted installs, collected other stats and phoned that home. Those companies put wrappers around installs. Scarf also installs a wrapper around your package. Imagine if every npm package did this in a single project. You'd have 100s of sub-sub dependencies phoning home.
> [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=""`
> You'd have 100s of sub-sub dependencies phoning home.
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.
Just wanted to mention that the site does not show anything at all with 1st-party JavaScript or 3rd-party JavaScript (stripe) disabled. It would be nice if there was some plain-old HTML ;).
Thanks for the feedback. I made the choice to make Scarf a single-page-app site, so yeah nothing really works without JS. Good to know this is a desire, will keep that in mind for future work :)
Make it first-party, then. At least for your landing page. I don't expect to have to load third-party scripting from a commerce website just to be able to see something other than a blank screen.
Hmm hitting enter for me right now does do the correct thing, what browser are you in? In any case, those routes colliding like that is an issue, I'll fix it shortly.
In firefox, if I put something in the search box, press enter, it will search. If I press enter a second time (taking no other action) it will display json.
Ignore Scarf's success for a moment, and focus on it's goal. Do you think FOSS developers should be compensated for their work? If so, how do we make that happen?
I actually disagree with this. Patreon doesn't target contributions from companies, only other indie developers for the most part. I've seen massive OSS projects that only get a very small amount of donations, so it's not a great solution for most developers.
This is a terrible idea. I like the idea of paying money to not be spied on--I wish more companies adopted that model--but turning your opensource project into spyware and holding privacy ransom is just so evil. It's also incredibly naive and detached from reality. Most people are not going to be okay with this, so what will happen is that they will either fork you or create an alternative that respects your privacy rather than pay up.
I understand where you're coming from. I think saying it's evil and holding privacy for ransom is inaccurate though. The goal of this is to give individual developers leverage to charge companies who profit from their work. People who wish to use your package for free and do it completely privately can still download your source code and run it. Scarf doesn't take away anyone's ability to do anything. It aims to augment existing software by offering a path for easy installation with telemetry and payments set up already. Nothing gets baked into the software, it's all at the distribution level.
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."
versus
"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.
Thinking aloud:
* 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.
https://scarf.sh/packages/search/framework
Thanks for the feedback.
EDIT: should be fixed!