
Show HN: Scarf – Platform to help open-source developers monetize their work - aviaviavi
https://scarf.sh
======
greggirwin
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.

~~~
fragmede
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.)

~~~
aviaviavi
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.

------
andrewstuart
Money is more likely to flow to open source developers if it is framed from
the perspective of the person/company that is paying:

"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."

~~~
aviaviavi
Noted, I'll certainly be updating the copy/documentation substantially. Thank
you!

------
weego
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

~~~
aviaviavi
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.

------
human20190310
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.

~~~
aviaviavi
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

~~~
tssva
What would also be great is to create a link to your terms of service so they
can be reviewed before creating an account.

------
jaboutboul
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/](https://tidelift.com/)

~~~
aviaviavi
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.

------
itsmefaz
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.

Would love to hear alternative views...

~~~
aviaviavi
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.

~~~
greggirwin
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.

------
xgulfie
Some site feedback:

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.

~~~
aviaviavi
Thanks for the feedback! I'll fix that shortly.

------
undoware
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._ )

~~~
misterdoubt
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."

~~~
aviaviavi
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.

------
andrewpierno
nice work! I have a similar project [https://ligit.dev](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?

~~~
aviaviavi
ligit looks cool too! perhaps we should chat about collaborating? Scarf
currently doesn't do much for the developer in terms of licensing.

Scarf could in theory install packages directly from the registry, but I
haven't looked into it much.

------
philips
So the high level monetization model is:

\- Free: metrics get sent to the scarf service

\- Paid: no metrics get sent to the scarf service

Is that correct?

~~~
aviaviavi
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.

------
vortico
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.

~~~
dboreham
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.

~~~
aviaviavi
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

------
mmgutz
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=""`

~~~
aviaviavi
> 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](https://github.com/aviaviavi/scarf)) so
there is full transparency to what data is captured and sent.

------
danieldk
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 ;).

~~~
aviaviavi
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 :)

~~~
mattl
Please consider making it work without JavaScript, or at the very least label
your JavaScript files so it will work with LibreJS.

~~~
aviaviavi
Thanks for the feedback, check back soon for the updates :)

------
garysahota93
This is awesome. I love open source projects and the developers behind them
all. This is really cool and I'm installing now!

------
flixic
Your search URLs return a JSON instead of HTML. I get this even when I press
Enter in a search box.

[https://scarf.sh/packages/search/framework](https://scarf.sh/packages/search/framework)

~~~
aviaviavi
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.

Thanks for the feedback.

EDIT: should be fixed!

~~~
lost_name
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.

------
cheez
Nearly every open source package that sees use will be added to free-as-in-
beer repositories. I don't see how this gets any uptake.

~~~
greggirwin
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?

~~~
cheez
I think Patreon-esque approaches + consulting is doing a decent job.

~~~
aviaviavi
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.

------
madradavid
Does Scarf use Scarf?

------
bogwog
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.

~~~
aviaviavi
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.

