Monetized JavaScript Packages?
Hey Indie Hackers—especially folks in the JS ecosystem,
I've been noodling on an idea, and I can't tell whether or not it's a terrible idea. I'd love it if you could help me decide.
The basic gist is this:
- you publish JavaScript packages to a registry (just like publishing to npm via
npm publish) - people purchase those packages and access them using standard JS tools like
npm install.
You can charge whatever you like for the packages you develop and people who purchase them can easily access them and integrate them into their products.
Here's a couple use cases (although there's probably others):
- project boilerplates
- premium frameworks that receive regular upgrades
- paid UI kits
- potentially code developed for clients
Here's a landing page I've set up trying to explain the idea a bit more: https://premium-js.carrd.co/. (just note—don't try to fill out the sign-up form... it isn't wired up :) )
I don't think something like this exists yet...but I'd love to know if so.
Look forward to hearing your take.
Trending on Indie Hackers
https://privjs.com - a similar platform already exists mate
@prasanna, thanks for the ping. I found your work via another platform just this morning and signed up. Looks like your just getting started this year? Good stuff.
yeah. actually started it last month.. I see that both of us are working to solve a similar problem. I hope that both of us succeed :)
Wow, you’ve made a ton of progress for a month. Kudos.
I hope so too. I think there’s enough space in the market for two products ... JS world is huge these days :)
Let’s connect and learn from each other
Thanks! I kinda went all into this project due to COVID-19. I was stuck a lot of times while building the private registry, and there's a high chance that you would face similar problems too. So, in case if you are stuck anywhere or would like to chat, please feel free to reach out to me on twitter or on my email: [email protected] I would be happy to help :)
Love the idea @jones_spencera! I've thought about something like this and it's great to see your plan.
I think most packages will always be open source and free, but I'm always happy to pay for something if it saves me time. For example, there are many free UI templates but I recently bought TailwindUI and totally love it! I think it could work with JS packages as well.
I'm not totally clear on how it will work with boilerplates because you can't install them into an existing project. Most of the time this boilerplate is your starting point, so how would that work? Would you just download the whole project through your registry?
And what about discovery, do you also plan to build some sort of discovering platform? When I launched React Milkshake, a React boilerplate, I found out that there weren't any specific places where you could discover these kinds of things. There are more paid boilerplates out there, but they can be hard to find. That's why I'm also working on a (yet another) new side project called CodeShield - A platform for discovering premium resources. Here is a demo link: https://codestash.now.sh (It's still very basic.). Maybe this could also be a nice place to discover premium JS packages? ;)
@jakeprins ... updated the landing page and you can now signup for the email list: https://premiumjs.com
Appreciate the sign up if you're interested!
Btw, codestash is looking sharper by the day. Nice work :)
Subscribed!
Woo! Thanks!
Btw I’m having another project on my roadmap that could also be a fit for premiumjs. A new boilerplate for building serverless applications with React. This starter-kit will be focused on building a SaaS business and includes features like Stripe integration etc. You can subscribe here to get notified whenever that’s ready (could still take a while): https://serverless.page/
@jakeprins, subscribed!
Also, dude—you have so many projects! How do you keep it all up? (And, you've got kids too right?)
Cool, thanks!
Yes I do, and to be honest, I'm sometimes struggling to find a way to combine everything. I'm spending most of my free time with my family, but whenever I have an hour to spend I'm putting it in one of my projects.
I believe that small consistent effort can take you quite far.
I feel that. I’ve got two little ones at home too and a pretty demanding day job. It’d hard to keep everything in the air and still get sleep :)
I like the small, consistent effort angle :)
Thanks @jakeprins for chiming in!
I think boilerplates would be something like this (after setting purchase and setting token...):
npx [@react](/react)-milkshake/pro project-name. You'd just have to publish a package that installs the latest version of the boilerplate in a directory calledproject-name.Discovery is an important point I hadn't considered! Codestash looks cool, and definitely an important part of premium resources is actually finding them.
Btw, I was looking at TailwindUI and am seriously considering purchasing. I only didn't at the time because I didn't have a project I was needed it for at the moment. How is the source code delivered?
That looks look a nice approach, sounds good!
Yes I liked TailwindUI, especially because I didn’t had any experience with tailwindcss, and I now I really like it.
When you buy TailwindUI You can login to a portal where you can copy the html like in the examples. Works fine for me. I was wishing for some more components, but they are working on it and keep adding new stuff.
Hey @jones_spencera 👋
Love the idea 💯
This is very close to what I started out doing with https://saasify.sh, specifically focusing on monetizing open source JS/TS packages that could be deployed as serverless functions.
Here's a talk I gave awhile back about different approaches to funding open source that you may find useful: https://slides.com/saasify/the-wonderful-world-of-open-source#/
I've learned a lot over the past 15 months and have mostly pivoted away from this idea because:
Love where your head's at though! Happy to chat about this idea further if you want. 😄
To branch off of point #1 there, as a developer; integrating external API's/packages is risky because you are essentially trusting the developer of that package to make something bug free and easy to use. Aside from popular and widely trusted packages and frameworks, I'm always reluctant to including public packages in my projects, and see inclusion of them as incurring a cost up front.
To request additional $$ costs?? Forget it. I'll find something open source with a lot of stars.
Hey @saasify, thanks for you sharing your perspective! Really appreciate it. What's a good way to contact you so we could chat more about this?
Join the saasify beta, fill out the typeform, and sign up for a time on my calendly. Happy to chat.
Done! Look forward to connecting!
I was actually looking at something like this for Nodewood - but it's not very common, it seems. I settled on a similar method to what others are suggesting - the CLI is an open-source NPM project, but once you auth with that, it will contact a private server to download/update code.
I'm writing all that auth stuff myself, since I couldn't find anything that works for me, but it would have been nice to be able to just integrate that service in from somewhere else.
@DanHulton, yeah, seems like there's a couple tactics folks have taken but nothing standard.
What are you wiring together to handle authentication and delivery Nodewood?
Pretty simple - you'll generate an api & secret key in the Nodewood app, similar to how Amazon does in their console. Then you save those in a .gitignore'd config file, which the CLI will send along with requests to download/update the framework.
@DanHulton makes sense!
good stuff check out https://licensezero.com/
Nice! Haven't heard of that..checking it out.
I've been bouncing this idea around with a design system and React Component library. I still haven't figured out how I would do that, but this thread has opened my eyes to some possibilities. Let's keep in touch! I want to hear what solution you end up going with–and the same from me.
@skillthrive, I updated the landing page... which you can find here: https://premiumjs.com.
If you're still interested, would love a sign up :)
Thanks, @skillthrive! I'll follow up... giving you a follow in the mean time!
Have you heard of gitstore? @jones_spencera
https://gitstore.app/features
@skillthrive.... oooh. Nice! I haven't heard. Good find.
I both like and dislike the idea.
It would be cool to have a place where high quality code, or at-least javascript packages that do what they say on the tin, can be found.
I would write some packages if I could get paid for them etc. from such a package manager.
These packages would have to be tested somehow, ie. chosen to adhere to the standard.
downside, it's javascript. Once one person downloaded the package and it being opensource, it could just be spread around for free....
I think the spreading around issue isn't such a problem, since most deploys / CIs will be pulling all of your packages and dep-solving during each launch. That won't work without a key. You could just statically link the dowloaded package, but in that case it wouldn't be getting updates and it wouldn't be in your dependency graph.
That’s true when you’re using packages that way. Not everyone trusts that npm packages that get pulled in will always work correctly. I’ve been bitten there a couple of times. I like to find packages that work, then bring them into the local source. That way I have control over all the source, not just my own.
Yup, that's definitely a valid approach. My preference is to pin versions in my package.json so I can be sure I'm using the exact same version I'm working on in dev. If I want to modify the source of a package I fork the repo and make my changes there, that way I can either commit it back to the mainline or pull in upstream changes from the mainline into my own package. Makes updating packages to get fixes / improvements a lot easier in my experience.
in my experience and many others as well, package lock doesn't actually lock. it can be overwritten and you end up with strange behaviour.
You're right, I think I'll start forking out the package I want to use.
Thanks for the tip
Glad you found that helpful!
I totally agree on the package lock being a potential source of issues. One thing you can do if you're worried about that is specify the exact package version you want in your package.json and you'll always be guaranteed to get that version.
Note that you can also be a little more general in your versioning if you want. For example, you can keep the major and minor version fixed but accept patches with, something like:
Package.json supports semver, so there's a lot of conrol there, which I generally like.
https://bytearcher.com/articles/semver-explained-why-theres-a-caret-in-my-package-json/
Thanks for chiming in @airshanemode. Good points!
Yeah, how high-quality and reputable the packages are is definitely a concern. Might be possible to do a rating and review system or something too.
True about spreading it around—but isn’t that true of lots of things like music or movies? Anyone could copy a CD once you put it out... maybe code distribution is different tho.
It would be better to simply provide the JS package on NPM and have it internally fetch necessary data using an API + a token tied to the user's account.
This is better for you, too, because then your business is simply to maintain the actual component you're delivering... no unnecessary maintenance of the registry.
Thanks for the reply! Yeahs, that’d definitely be easier.
I have a suspicion it wouldn’t work with npm terms and conditions. I’ll read them to see if that’d be allowed. I’d just be worried they’d cut the product off and it’d kill all people relying on that registry
This is how fontawesome does it. That's a hugely popular package, so I'd think it must be fine with NPM.
https://fontawesome.com/how-to-use/on-the-web/setup/using-package-managers
Just read all of npm's Terms, and they're surprisingly brief. This seems to be the only thing related to paid services: https://www.npmjs.com/policies/private-terms. This seems to be all they say about it:
So, yeah, seems like fontawesome is above board.
Awesome!
Hey Spencer,
I have used the same idea in the past for some Angular admin themes of mine. I was maintaining a premium theme with internal, private, tailormade components.
Basically, I was using Themeforest as a marketplace and provided a custom NPM registry for those who needed frequent updates. Verdaccio is a great solution as it works as a lightweight proxy around NPM, it also has a few plugins for payments, caching, and authorization.
My 2¢: It's a great idea and a viable plan especially for freelancers or as a side project. I would highly suggest delivering a product like an admin panel or even a blog theme where your packages are the building blocks, I tend to believe that just selling a component or a framework doesn't make any sense as there a ton out there.
If you want any insights, metrics or suggestions let me know :)
Cheers.
Thanks!
I’ve been looking at Verdaccio—came across it researching this topic to see if this already existed. Did you basically just deploy a Verdaccio server with a username password that let your clients download that when they wanted?
Kind of yes. Since I was using Themeforest I was able to use their API and produce tokens for every purchase, afterward, I was emailing the tokens to my customers.
There is a big caveat here though since Verdaccio works like a proxy and it should check your own registry for private packages you may be facing lots of traffic, in that manner the cost of maintaining a private registry can be huge.
The other idea I was experimenting with was using Gitlab as a "registry" which is basically free of charge and easy to maintain. Furthermore you can use the issue tracker for bug reports.
Thanks for the tips!
Hey @vorillaz, I've updated the landing page and you can now sign up for the email list: https://premiumjs.com. If you'd still be interested, would love a sign up :)
That's a cool idea.
One simple solution would be to give access to a private git repository for buyers, and then they can install it directly using npm.
Thanks for the reply! Yeah, the npm interop with git might make that possible
Pinging @jakeprins. I know you’re developing a premium boilerplate for React—would love your take.
As a package producer, I really like the idea.
As a consumer, what value am I getting from paying for these packages? Am I getting higher quality projects than the ones being offered for free? I can't image there won't be free packages that offer equivalent functionality.
In your FAQ section, I found this:
I'm curious if you could use npm as the package manager for this instead of moving them to a new package manager. NPM offers package feeds. Would it be possible for, when a customer pays for your package, a private package feed is created in NPM for that customer? Then they can just provide their same credentials to NPM. -Just a thought.
Ps. Awesome job bringing your proposed site to the table. It really helped me wrap my head around the concept.
Hey @matthensleyio, thanks for the reply a few weeks ago. I've updated the landing page and you can now sign up for the mailing list: https://premiumjs.com
Appreciate the signup if you're interested! :)
Thanks for the reply!
Agree—The JS ecosystem is vibrant and there’s lots of free code available via the package managers and public registry. But there’s lots of code for sale too right now and there’s not great distribution channels for them.
For instance, someone could purchase and download a zip file—but what about upgrades? The distribution of those files don’t play nicely with existing package management tool chains.
So, I guess what I’m trying to say is people are already buying and selling code—and when people buy it, the tools to integrate it into their software aren’t great.
Could you say more about npm feeds or point me to a link? I was searching around but not finding something that would help me understand.
I was meaning, for example; when someone purchases a license for a paid package through your website, you could then automatically create a private NPM feed for that customer's packages. The customer could use that private NPM feed, managed by you, to download the package & be given any future updates.
This would keep both your creators & customers using the NPM ecosystem they are already familiar with while also being able to easily manage licensed packages.
Here is a short page about NPM private packages.
Got It! Thanks. It sounds like this is similar to what Font Awesome is doing, and with this implementation, it’s basically just productive that.
This comment was deleted 2 years ago.
@peterparker- thanks for the reply!
Actually, I think this is the exact same case ... except—you would get a token and still use the npm CLI in both cases. You just wouldn’t be using the npm registry for that one package.
I didn’t know Font Awesome offered that. So when you purchased the pro version, did they just give you a key that lets you download it from npm? Or some other way?
This comment was deleted 2 years ago.