[HN Gopher] Kill Bill - Open-Source Subscription Billing and Pay...
___________________________________________________________________
Kill Bill - Open-Source Subscription Billing and Payments Platform
Author : Whitespace
Score : 280 points
Date : 2022-10-19 15:26 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Whitespace wrote:
| Submitted the github link because I couldn't find it from their
| marketing site: https://killbill.io/
| Operyl wrote:
| I went on a trip to see how hard it would be to fine, and I
| _sort of_ found it, and it was not obvious.
|
| 1. Started at the homepage, clicked "Start Now" at the top
| right. It lands on a page called /download/.
|
| 2. The word download is nowhere to be seen on that page, but,
| the third box in the row is "On premise", and has a "Select
| plan" which redirects to https://github.com/sponsors/killbill.
|
| 3. We land on the Github sponsors page for the org. The
| repository is listed below.
|
| Yeesh, that was a trip of obfuscation.
| jlund-molfese wrote:
| It is hidden in the FAQ too-- https://killbill.io/faqs/#faq-
| item-where-is-the-code
|
| But yeah, not emphasizing their GitHub page is an interesting
| choice, maybe they figure that their audience isn't
| developers? Although many of the reviews are from technical
| people, so that doesn't make sense either.
| zinclozenge wrote:
| It's pretty absurd that the quickest way to find their (and
| honestly a lot of companies') github is by googling
| "companyname github".
| marykms wrote:
| We have corrected this oversight! Thanks for noticing. It's now
| under the About menu.
| ranger_danger wrote:
| Very unprofessional name, this is not something I could even
| bring up in a commercial setting if I wanted to use it. Please
| consider a different name.
| newone2three wrote:
| Why?
| jjgreen wrote:
| In the UK, "the Bill" is "the old Bill", the police. "Kill
| the Bill" is a favoured chant by cross anarchists opposing
| the "Take-Away-You-Freedom bill (2023)", and/or wishing an
| early demise to the police.
| veb wrote:
| my first thought was the movie. but if you think about it,
| they're talking about killing billing problems so I'd say
| that's where the name comes from. (if you check out their
| website).
|
| a name that makes people go "hmm that's a bit odd" is
| actually a very efficient way to get people to remember it
| next time they need them.
| jjgreen wrote:
| That's true enough ... hmmm ... [searches web to see if
| anyone is making "CopKilla soda"]
| geoffeg wrote:
| Big Ass Fans (https://bigassfans.com/) has what some might
| consider to be an unacceptable/unprofessional name and they
| seem to do great. One might argue that they're "unprofessional"
| name has helped them.
| ranger_danger wrote:
| There is no comparison between murder and a buttock.
| incomingpain wrote:
| Say I had an project that produces a file that people will
| subscribe to get access to said file. Is this what you would use
| to sell it? Why not say shopify?
| thedangler wrote:
| Shameless plug -You can use my stuff sytescope.com $20/m CAD
| jmacd wrote:
| That really strikes me as a better use case for Square or
| Gumroad than either Shopify or KillBill.
| thedangler wrote:
| And shameless plug... sytescope.com lol You can have password
| protected sections or email digital products after purchase.
| modeless wrote:
| Maybe this is a good place to ask. I'm considering trying a
| subscription model for some client side software I'm developing
| as as a side project. I think something like this would be
| overkill for me. For a single developer project, what would be
| the easy way here? Using something totally managed like Patreon?
| Would Patreon even be a reasonable choice?
| ggregoire wrote:
| Stripe (and its competitors) solves exactly what you need.
|
| It takes 1 or 2 days to integrate into your app [1] and you
| more or less never have to deal with it again (i.e. very low
| maintenance/administration).
|
| I also think it's worth learning just to have an understanding
| of how online payment works.
|
| --
|
| [1]: 1 day for a basic subscription model, with granting or
| removing access when the payment succeeded or failed or the
| period is over and a new payment hasn't been done.
|
| Maybe 2 days if you want to handle different plans (e.g. free,
| basic, pro) giving access to different features, and also like
| a 14 days free trial.
| adave wrote:
| Just remember when you run into problems or have a spike they
| will temp ban and hold your funds so just like paypal.
| Depending on your situation the convivence might be worth it
| though. Do consider pros and cons as it'll be painful later
| on.
| victor9000 wrote:
| If you don't mind coding in php, check out Laravel Spark.
|
| https://spark.laravel.com/
| nickstinemates wrote:
| Stripe is pretty straightforward if you're taking in USD
| mansilladev wrote:
| I typically think of Patreon as a way for content creators to
| charge folks for "memberships." So, while I think their billing
| mechanisms may work for you from a mechanical perspective, I'd
| perhaps look at alternatives for monthly billing for your
| client side software licensing.
|
| As for Killbill being overkill.. I think that running/managing
| your own payment/subscription service behind the scenes
| probably isn't something you want to spend your time doing, nor
| would your customers want you spending your time on. Search
| google for "SaaS billing" and you'll find plenty of options to
| choose from.
| modeless wrote:
| Yeah I know what Patreon is typically used for, but I'm still
| figuring out what will work best for me. It's possible that
| positioning myself as a content creator would be OK, with the
| software mostly free, maybe even open source, but a few paid
| features unlocked by Patreon. Or something. It's a developer
| tool and I think developers want everything to be free and
| open source so it will be tough to monetize.
| dewey wrote:
| Look into Paddle or Stripe Checkout. It can be as easy as just
| dropping in a link if you want to do it half-manual until you
| have the need for it.
| javier2 wrote:
| This sounds like a awesome idea and a great project, and I work
| with subscription billing. Attempted to try it out for a while,
| and my first impression is that the UI is terribly ugly, even as
| I literally could find only 3 buttons to click a side from the
| Log out button.
| mpaepper wrote:
| If you use this in combination with Stripe, then what do you gain
| in addition to Stripe?
| paulryanrogers wrote:
| One would hope you'd be decoupled from their rebilling, and
| therefore could swap vendors more easily.
|
| I actually just ran into the need to bypass Stripe rebill
| recently. Ultimately a workaround was found, yet sometimes you
| really just need more control.
| pamonrails wrote:
| It really depends on your usecase, but some benefits:
|
| * Lower cost (just pay for payment processing, not the
| subscription features) * Ability to integrate with multiple
| gateways (to lower cost, support more payment instruments,
| higher resiliency, etc.) * More advanced subscription features
| * Ability to customize the system through custom code (plugins)
| * Data ownership (easier to run analytics reports, since you
| own the subscription data)
| jmacd wrote:
| They have a cloud offering. [1] Which is a good way to check
| things out without needing to deploy and run Java code.
|
| 1: https://cloud.killbill.io
| pamonrails wrote:
| FYI this is just a managed sandbox, to test things out. We
| don't offer Kill Bill aaS, as it goes against our value
| proposition (Kill Bill is a framework to build your own
| internal subscription billing and payments platform).
| onebot wrote:
| Nice to see stuff like this. But won't use it since built on
| Java. I try to avoid the JVM as much possible.
| hartAtWork wrote:
| A significant amount of the worlds software runs fine on JVM
| vlunkr wrote:
| I hear 3 billion devices run Java.
| [deleted]
| canadiantim wrote:
| As an alternative you can use: getlago.com, which isn't built
| on Java
| readams wrote:
| Lago is AGPL so no go.
| Andrew_nenakhov wrote:
| If you are not modifying it, this is the same as MIT in
| every practical way.
| throwup wrote:
| Beggars can't be choosers. If you're going to reject every
| open source solution, you might as well just sign up for
| Stripe.
| rexreed wrote:
| I'm not too familiar with the problems of AGPL - what's the
| specific issues I should be concerned with Lago being AGPL?
| hobo_mark wrote:
| https://opensource.google/documentation/reference/using/a
| gpl...
| cupofjoakim wrote:
| Care to explain why?
| onebot wrote:
| Java was great at the time it was created. But now, I think
| there are several better languages that are more suited for
| today. Like Go as an example. Easy to develop and easy to
| maintain. You get very good performance for little effort. It
| is just my personal preference, but I don't care to maintain
| Java or JVM anymore. FWIW, I was at the very first every Java
| One conference. Have used it for many years.
| mahmoudimus wrote:
| It might make sense to revisit your stance given the most
| recent JEPs that have been introduced. Java 19 introduced
| virtual threads and structured concurrency, which will
| arguably make Java + the JVM a great alternative to Go,
| etc. Especially since it's very backward compatible.
|
| W/ Graal as well, the AOT compilation comes 90% of JIT
| performance.
|
| I really think the JVM is an exciting eco-system that has a
| very bright future if it keeps going the way it is. Brian
| Goetz' "Paving the on-ramp" discusses how to reduce the
| boilerplate even further. So these things are definitely a
| priority for the Java/JVM team[0].
|
| [0]: https://openjdk.org/projects/amber/design-notes/on-
| ramp
| AzzieElbab wrote:
| I haven't seen a single business app written in Go
| password4321 wrote:
| Oracle / licensing
|
| edit: IIRC the official Java runtime auto-update happily
| upgraded to not-even-free-as-in-beer pretty nonchalantly.
|
| https://news.ycombinator.com/item?id=28543265 (2021)
|
| https://news.ycombinator.com/item?id=20799424 (2019)
| chrisseaton wrote:
| It's GPL with the 'classpath exception' so that you're even
| exempt from the GPL the you link. Seems pretty good
| licensing? Do you prefer even more permissive than that?
| mahmoudimus wrote:
| This is no longer a real reason. It's licensed as GPL with
| a "classpath exception." That's pretty permissive and this
| article[0] does a pretty good job of explaining some
| questions you may have.
|
| [0]: https://www.mend.io/resources/blog/top-9-gpl-with-the-
| classp...
| anotherrandom wrote:
| I don't understand this complaint anymore. Hotspot and
| OpenJDK are all GPL, licensing and Oracle aren't worries at
| this point
| zinclozenge wrote:
| I'm not the OP, but generally JVM applications are very
| resource hungry under small loads, although I will concede
| this matters less as load increases, and the extreme OOP
| style of programming that Java encourages, in my opinion,
| leads to a lot of faults that require more operational
| babysitting than I'm ok with.
|
| I don't have any empirical evidence, just experience. As such
| I'm very biased against it.
| sieabahlpark wrote:
| smashed wrote:
| That's very harsh. If it were a bunch of cobbled together perl
| and bash scripts I could understand poopooing the software
| stack, but java for enterprise accounting software is a super
| common stack and arguably one of the most suitable solution for
| this type of software.
| inson wrote:
| Or Kotlin. People usually complain about JVM but lots of
| enterprise software runs on it. Spring boot ecosystem
| provides lots ready to use libraries. Kotlin can be much
| easier to use compared to Java. Yes Go can be better language
| now, but still lacks lots of library and API support. And
| Rust, I'd rather code in jvm language fast and ship it fast
| than building up whole infrastructure that takes way more
| time to implement.
| RamblingCTO wrote:
| In my main gig we run on kotlin (fintech/accounting saas)
| and I absolutely despise it, the overhead is massive. But I
| wouldn't want to write it in golang, we really need proper
| OOP. It's also so unbearably slow, it's actually
| impressive. But it is what it is -\\_(tsu)_/-
| djcannabiz wrote:
| what would you say is a fast language then?
| onebot wrote:
| It is just my preference. But your right, java is very
| "enterprise" hence my trepidation. I think there are much
| better enterprise worthy languages now, like Go. Which are
| far easier to develop and maintain.
| encryptluks2 wrote:
| Same here. It really is a headache and slow compared to a nice
| Go, Rust or C program.
| halfjoking wrote:
| If this supported tons of payment gateways through their plugin
| system out of the box then it would be worth considering. But if
| you go to the page about payment gateways they don't have a
| listing of 50 integrations you could easily drop in. Instead they
| basically say you'll probably have to write the integration
| yourself:
|
| https://docs.killbill.io/latest/userguide_payment.html
|
| No thanks - I'll just use a payment processor that has a good API
| for subscription billing, and a flag on my users table that the
| subscription is up to date.
| jmacd wrote:
| They do have Stripe, Adyen, CoCardless [1]
|
| I do agree this would be something a fully commercial project
| would/should focus on.
|
| https://github.com/orgs/killbill/repositories
| adave wrote:
| Yeah that's good sine the vendors get a lot of control for
| writing the basic API's. This is open source so they let you
| choose which means not getting everything spoon fed.
| leonidasv wrote:
| As a software engineer who focus on developing payments and
| billing systems, I assure you that gateway integration is by
| far the easiest part.
| [deleted]
| davedx wrote:
| Great low effort dunk on an open source project. Go you
| halfjoking wrote:
| Yeah I was too negative. Vendor lock-in sucks so I'm glad
| someone is tackling it and I should have started with that.
|
| But I think people shouldn't hold back criticism either just
| because something is free or open source. Stability AI
| (Stable Diffusion) just sold out and took $100 million from
| investors after being open source. Even if they're providing
| something altruistically now you never know if that will
| change after VC, buyout offer, or some other event.
| ihattendorf wrote:
| But the open source code is still there, the community is
| always able to fork and continue development. True, that
| rarely happens, but does occasionally (e.g. Emby ->
| Jellyfin).
| [deleted]
| pamonrails wrote:
| FWIW the very vast majority of our users are integrated with
| either Adyen, Braintree, or Stripe (all open-source plugins).
|
| I know of ~20 integrations with more advanced
| gateways/processors: these are closed-source plugins, but the
| overall community wouldn't benefit much from accessing them
| (e.g. it doesn't make sense for many companies to directly
| integrate with mastercard APIs).
| sdfhbdf wrote:
| It's interesting to see that even though the project seems to
| boast being about 10 years old it still doesn't have 1.0 version.
| For some this might not be important but it does seem to subtly
| convey a message of instability of the product. I haven't read
| much into it but have to wonder what is stopping them from
| releasing a "stable" 1.0
| dvt wrote:
| I mean this only makes sense in a world where everyone uses
| semantic versioning (and the project doesn't seem to indicate
| this anywhere). Versioning numbers, per se, don't really have
| any bearing on application stability.
| mccorrinall wrote:
| Even when using semver it just means that there were never
| any major breaking changes. React is also still 0.x :)
| [deleted]
| dvt wrote:
| Interestingly, being `0.y.z` as a major released version
| (e.g. not in development or a release candidate) does seem
| to break semver[1], but I do realize it's more of a
| guideline and no one really cares:
|
| > Major version X (X.y.z | X > 0) MUST be incremented if
| any backwards incompatible changes are introduced to the
| public API. It MAY also include minor and patch level
| changes. Patch and minor versions MUST be reset to 0 when
| major version is incremented.
|
| [1] https://semver.org/
| bitdivision wrote:
| For versions < 1.0.0 this does not apply:
|
| > Major version zero (0.y.z) is for initial development.
| Anything MAY change at any time. The public API SHOULD
| NOT be considered stable.
| riquito wrote:
| > React is also still 0.x :)
|
| It moved away from 0.x around 6 years ago
| lelandfe wrote:
| https://github.com/facebook/react-native/releases
|
| React Native is still 0.x, since 2015!
| pamonrails wrote:
| We don't follow SemVer (yet?).
|
| We use even minor versions for LTS releases (e.g. 0.22.x) and
| odd versions for dev releases (e.g. 0.23.x). Kill Bill is very
| much stable now :-)
| johnmaguire wrote:
| Don't be bullied out of ZeroVer - https://0ver.org/
| lgl wrote:
| Thanks for this gem of a link. I had a good chuckle all
| around but found this part particularly very funny:
|
| Apache Kafka was named after Franz Kafka, who lived as an
| author in turn-of-the-20th-century Austria. Like the
| project named after him, he was slow to start, inconsistent
| in delivery, and left a mess of unpublished work after a
| tragically early death.
| TedDoesntTalk wrote:
| Wish i'd known about this before signing up with Recurly and,
| later Stripe Subscriptions. Now existing subscriptions are locked
| in and I can't move to other vendors without losing those
| existing subscriptions.
| kareemm wrote:
| Stripe used to help you migrate away. Not sure if they still
| do.
| voiper1 wrote:
| Stripe indeed helped me migrate away to a vendor in a foreign
| country - they did a one-time encryption of all the raw
| credit card numbers for my new processor to import.
|
| The trouble was finding a processor that actually knew what
| it meant to import the raw credit card numbers (because
| stripe wouldn't send it to me). But I found one and it all
| worked out.
| btown wrote:
| I recommend Spreedly for things like this - having a card
| vault that's independent of your processor can massively
| de-risk operations and allow you to dynamically route
| specific transactions to different gateways to optimize
| profitability. While I haven't tried an import with them,
| they do support this workflow:
| https://docs.spreedly.com/guides/migrating/one-time/
| TedDoesntTalk wrote:
| > But I found one and it all worked out.
|
| Who?
| voiper1 wrote:
| In Israel, sumit.co.il was able to cooperate with Stripe
| to import my tokens. (I had to pay for some developer
| time.)
| nwilkens wrote:
| Also pretty interesting, Equinix Metal appears to be using this
| product:
|
| https://feedback.equinixmetal.com/changelog/new-kill-bill-bi...
|
| https://metal.equinix.com/blog/under-the-hood-kill-bill/
| manv1 wrote:
| We're hunting for a subscription product, but our use case means
| that we may have to do a few hundred thousand provisioning checks
| in a few seconds.
|
| Not a lot of products can do this, which means we're going to use
| redis (or it's ilk) as a cache for subscription information.
| However, there doesn't seem to be a supported way to subscribe to
| changes to subscriptions. Is that a roadmap feature or is
| something that "we should do ourselves?"
| jmacd wrote:
| I would love to speak with you to learn more. This is a very
| good use case for something I have been working on. My email is
| in my bio page if you are interested.
| aylons wrote:
| I'm sorry I don't have anything further to contribute to the
| discussion, but this is an amazing name for the project. The
| double-pun in the logo with the duck is the cherry on the top.
|
| Actually, here's a small contribution: I do not work with web
| apps or nowhere near this kind of development (yeah, I also
| wonder why I'm a regular at HN), or have a use to the end
| product, but the name and logo grabbed my attention enough to
| click the link, see the discussion and read the front page.
| There's power to clever branding.
| [deleted]
| rodelrod wrote:
| I've built a (proprietary) telecom billing system with the same
| name back in 2005. I can't claim that as a particularly
| brilliant pun since the system we were replacing was called
| "BillGates" so it was kinda obvious.
| inanutshellus wrote:
| It is a bit perverse, right? A solution called "kill bill"
| that... creates bills.
| sbrossie wrote:
| Perverse is a bit strong :-) To be understood as killing the
| 'billing problem'...
| inanutshellus wrote:
| One could say it kills problems, or headaches, or anxiety.
| But what does it create? It creates _bills_. "Perverse"
| seems like a pretty good descriptor.
| tmpz22 wrote:
| Is Groupon/HP/Square/etc really using this or is it just a fake
| marketing page?
| [deleted]
| pamonrails wrote:
| No fake marketing :-)
| rco8786 wrote:
| Can confirm that Square uses it internally
| paxys wrote:
| It seems to have been created by ex-Groupon folks, so that one
| is believable. Not sure about the rest.
| brianm wrote:
| It predates Groupon, was actually started at/around Ning (if
| anyone remembers them). Groupon hired a bunch of the core
| folks at the time they decided to adopt it.
| jmacd wrote:
| I've met with the founders of the project before. They really
| don't strike me as the bulls#$ng type of promoters we've all
| grown jaded over.
|
| They love this project and what they do.
| AngeloAnolin wrote:
| This is the type of project that should gain more traction /
| support.
|
| Good name as well. Catchy!
| pipeline_peak wrote:
| Normalize open sourcing things companies monetize that aren't
| really that special.
|
| Competition breeds innovation
| diamondage wrote:
| surely docusign is another target
| pipeline_peak wrote:
| Absolutely
| jonahbenton wrote:
| Met with this team probably 8 years ago for consideration on a
| (at the time) large subscription product. Didn't go with it
| because of issues in the organization I was working with, but
| KillBill folks were good people, impressive, good product. Glad
| to see them still around.
| AzzieElbab wrote:
| Tried to adopt it about 8 years ago but their very traditional
| architecture didn't fit well with the infra we were using. Also
| some jruby based plugins were buggy
| adave wrote:
| You mean the flawed microservices architecture where
| everything is so complicated it's almost not worth doing.
| pamonrails wrote:
| Fair. That being said, we've come a long way by now. Lots of
| our users deploy Kill Bill in "cloud-native" environments
| these days (e.g. k8s).
|
| Also, we've deprecated JRuby support. Plugins are either
| written in Java or in other languages through grpc shims
| (e.g. Go).
| AzzieElbab wrote:
| Great to see you guys take all the things into account.
| jiripospisil wrote:
| > Does Kill Bill support taxes?
|
| > Kill Bill does not support taxes. Instead, we partner with
| Avalara to outsource tax compliance. Our AvaTax connector
| provides real-time and on-demand calculationsto prevent
| overcharging or undercharging tax.
|
| I expected as much. Handling taxes internationally is a major
| PITA and it changes all the time as politicians get new ideas how
| to make things even more complicated. I'm pretty sure that many
| SaaS companies are unknowingly not compliant with all the rules.
| theturtletalks wrote:
| So you're saying we need an open-source Avalara alternative.
| Countries could even send PRs to change tax rates on the fly.
| saddist0 wrote:
| It is much more than paying taxes. There is no standard API
| to pay taxes even if you can calculate the amount. A lot of
| countries require weird registrations on weird portals upon
| crossing different thresholds. A lot of countries have
| different financial year cycle.
|
| And.. this is just the tip of the iceburg.
| lazide wrote:
| Or as often, knowingly not compliant with the unknown, and
| unknowable (at their scale) rules
| kingsloi wrote:
| Interesting name choice and idea, I may try it out if I can
| figure out how to run java again. I went with a similar name
| https://github.com/kingsloi/medical-billkill for an app I'm
| building to digitise medical bills
|
| oh I see it uses docker, noice
| https://docs.killbill.io/latest/getting_started.html#_docker
| seaourfreed wrote:
| If/when people get censored by their merchant processor, they can
| switch to this.
___________________________________________________________________
(page generated 2022-10-19 23:00 UTC)