Tidelift is insanely exciting and I can't wait for this to be the primary way open source software is built, sustained, and matured.
Funding for open source is a crucial topic for everyone here. Nadia Eghbal's lemonade-stand [1] - A handy guide to financial support for open source - shows the myriad of solutions that have existed over the years, and none have really stood out.
Unlike foundations who spend significant portions of their funding on executives and other services for a narrow subset of the OSS ecosystem, Tidelift is doing something novel by doing something simple. Make it easy for companies to buy a subscription to open source software that carries added commercial benefits [2] and then take that money and pay the maintainers. That's it.
For companies and maintainers alike, this seems ideal.
I also hope that in the future more open source development will be funded in a sustainable way, but as it stands right now I very much hope that it's not via Tidelift. Of all the approaches I've seen so far, Tidelift is among the most intransparent ones, and with that a very bad fit for open source in my opinion.
Apologies, I didn't see that comment before. The target customer is large organizations and the pricing is typical for that. We'll be getting a pricing page up that explains the details. There are conditions and commitments for maintainers, see:
This is a commercial transaction; subscribers are paying for value, and we are paying maintainers to help us provide the value. It is not a donation model. We think it is a favorable transaction for maintainers because it is royalty-style rather than hourly-consulting-style. The same amount of work can be sold N times.
For donations there are a number of existing solutions and we would encourage people to use them also!
> This is a commercial transaction; subscribers are paying for value, and we are paying maintainers to help us provide the value.
That's just not what your branding/advertising is telling me. I understand that's what's happening but the way you're billing it comes across like you're Patreon for open source.
Non-engineering spend at open source companies like RedHat or Anaconda is typically much higher than 50% of revenues. That includes sales and marketing, getting through the IT approval process at big companies, etc. all of which is difficult and pretty expensive.
I needed a good laugh. Thanks for that Wired! “How can I make money off all the hard work that developers do for free via open source.” I got it, let’s sell the free software back to large corporations, and take a 90% commission all the while making empty promises and giving the actual developers pocket change for the privilege. Thanks but no thanks.
I couldn't find any numbers (incl. your "90%"), more clarity would be appreciated, though I understand Tidelift is still an experiment. But this explanation [0] caught my eye:
> How we compute how much to pay
> A weight. …based primarily on code size with some adjustments…
So, payments based off a clear (and clearly silly) metric that's easy to game. What could possibly go wrong?
"That was risky, because Babel is open source—meaning it is freely available online, and users don’t have to pay for it."
I don't get why many seem to think that Open Source = No cost for the user. Now I haven't read up that much on the OS philosophy so that might be why, but I have read a bit about free software, like Free Software, Free Society:
Selected Essays of Richard M. Stallman[0] for example, how anyone could mistake free software as software at no cost is beyond me. You can of course make it available at no cost, but then, it's your problem if you're not getting paid. Free software basically means that you're free to review and edit the software as you wish, (with some other implications as well if you read up on the GPL-3.0 license) and as far as I know, that's basically the purpose of open source as well. I thought companies, or developers, made their code available to get feedback, find bugs and issues more quickly, show the rest of the world that they have nothing fishy to hide etc. But I had no idea that it also meant that code automatically became gratis for everyone.
You can try to sell open source software. The problem is you can easily be undercut, because anyone else can sell it too, or even give it away. As the original developer, you're actually somewhat at a disadvantage, as you have to pay for the expenses of development, while your competitors do not.
It's pretty rare for anyone to make money directly from selling their open source software. Most open source business models involve selling something else, like support or hardware.
The elephant in the room here is the WordPress add-on market. There are thousands of devs doing a thriving business selling themes & plugins, all of which have to be GPL licensed, with basically no trouble. If you want a model for successful open source commercial development, that’s it.
you can absolutely sell your code and still license it under GPL. Just, if someone buys it, and it is really GPL licensed, then they must be allowed to redistribute it without further restrictions. So any third person can then get it for free. So the only reason to buy it from you would be "because it's the sane/right thing to do" which makes it look very much like a donation...
IIRC there was a project that tried a "we give it to you as GPL, but if you redistribute it, we'll not sell you future versions" kind of deal. I want to say some kernel patch set? At the time there was quite a bit of debate about whether that's okay
There are a few games that I know of with free software licenses (one with the GPL) that sell their software no problem. As others have mentioned, free software (and open source software as well) do not disallow redistribution. So if you have obtained a license for the software (by buying it for instance), nothing is stopping you from giving it away for free (or selling it yourself). In a large market, this will cause the price to tend towards zero.
In practice, though, at least for the games I know about, even though they are free software, people prefer to buy them for various reasons. A few of the games are on Steam, and some people just like to buy games on Steam. They don't mind forking over a small fee for the convenience of having everything in one packaging system. Some games have official servers that you can't use without paying money, so most players prefer to pay the money and use the official servers (instead of having to maintain their own).
For other kinds of free software, I think most people do not have a business model in mind when they write the software. If it's part of a company initiative, having other developers trained in your code base before they join the company is well worth the effort of freeing up the software. Zero price reduces the barrier to entry.
There are a few companies that have tried to make a pure Free software play. Werner Koch has funded himself and occasionally a small team for GPG development with various contracts. I think he's well funded now from donations. Probably the most famous and successful pure Free software play was Cygnus software which did the development for GCC an the Autoconf tools for a decade or so. They grew their business from $3K to selling out to Red Hat for $600 million. They just had a good business plan and a product in the perfect space (making GCC run on embedded systems for large corporations). Another example is Code Weavers which is technically open core, but I think pretty much everything they do ends up in Wine eventually. Again, customer development for large organisations in order to allow Windows apps to run on Posix systems.
Quite a few free software systems work in a kind of consortium model. That would include organisations like Apache -- a group of big companies get together and agree to fund the development of certain projects because it makes sense for them to share development costs. Another very good example of that is Blender and I think their business model has been extremely effective -- get funding for small projects that make them relevant to the movie industry and then reap the benefits from the consortium model.
There are quite a few more, but you get the idea. The main thing about Free and Open Source software is that it's hard to have a pure play if your product is software. If you are selling services, or doing custom development, or are aiming to make yourself indispensable to a certain industry so that they fund you... you can do it. If you want to charge for your software (like the games I mentioned above), then you pretty much have to hope that there is a reason why your customers will choose to pay you rather than trying to find the software somewhere else. That might be difficult (but like I said, I've been surprised that some people are actually able to make a living at it).
> But I had no idea that it also meant that code automatically became gratis for everyone.
I think it's common sense. If I sell you a software and provide you the source code with a GPL license, you are free to publish the code online for everyone to download free. So yes, open source invariably implies no cost to end user.
You are free, but won't necessarily do it. At a previous company, 90%+ of the code I wrote was (A/L)GPL licensed, yet we sold it (to companies) and our clients never redistributed it. The only code available publicly was the one we purposefully shared.
This probably wouldn't work in many cases (particularly consumer software), but a trucking company or a clothes manufacturer has no interest in becoming a software distributor. They just like not being locked-in to us.
"When a customer signs up with Tidelift, the company analyzes the customer's code to see what open source software it depends on, and what open source projects those programs depend on. Tidelift then charges a subscription fee based on the number of participating projects a customer relies on."
Sure, just run `npm install` and try to come up with a reasonable number that will look like something i'll be willing to pay for.
The sheer amount of open source code that pretty much any software out there runs on is absolutely astonishing. Especially when you start taking into account transitive dependencies. Say I'm running Java... Someone had to compile the JVM and it was probably done on an open source compiler.
Crazy to think of how many thousands of man hours have gone into something as simple as allowing me to argue with someone over the internet.
Hi, Tidelift cofounder here. This is a reason we don't charge per-package. It costs the same whatever customers report. (Which is what the Wired "Netflix" analogy is about.)
The incentive to report accurately is that subscription benefits only apply to packages we know someone's using. Some of those benefits are dependency analysis results, others are services or assurances. For example, we'd only know to tell them about security vulnerabilities in a package they actually say they use.
It's analogous to something like Code Climate, Coveralls, TravisCI, etc. Some companies require an on-premise version or want to run the scan themselves and only call an "upload my dependencies as JSON" API, which is fine. The scan is only to get the list of deps and their versions, it doesn't care about the actual source code.
For a Java program, just gather the "import" declarations from every single source file. Consolidate those into a single file, removing duplicates, sort them.
You now have a list of everything used by your program. Remove all of the internal imports. That is imports from other parts of your own software. (Hint: this is easy since they are sorted by package name.)
Now you have a list of all third party software used.
I suspect this same procedure works for C / C++ / Python and probably other languages.
You don't have to give anyone your source code to discover what third party and open source software you are using.
You mean providing leftpad to the world isn't worth a buck a month from thousands of different people? I mean, that might have taken someone a while five minutes to write. If they weren't that familiar with JavaScript and had to look up some stuff in the docs that is...
I am oblivious to some or many aspects of Tech. business. It is probably going to cringe a lot of people, but the question in my mind is, Why cant Dell or other OEM's pay for developing or customizing Linux to their specs, so it is more reliable. That way they don't have to depend on Microsoft for OS and can optimize their hardware performance, just like Apple does with OSX? I know it sounds like a dumb question, but I don't know any other place on internet that provides a better answer than here.
They do already and have been for a couple decades. Dell in particular has had a long history of doing so. Personally, I have worked for a couple companies that have done just that. Now when you look at certain classes of machines for specific workloads you will see engineering specifically for Linux. But when most people look at MSFT & Apple they are thinking about the desktop. And if you look in certain corporate environments, you will find Linux thin clients, but those tend to be very specific highly regulated environments.
I don't think that's at all impossible for Dell or the other OEMs to do (and I think some of that might already be happening a bit) but overall I don't think they particularly mind using Windows for their computers. There's a whole class of customer support issues that another company has to deal with for them, they avoid the "why can't I install this program that my daughter sent me?" type problems and overall they just give their "learned about computers in the 90's"-business segment exactly what they expect.
They do pay for drivers and other engineering work. I don’t know how it is now but Canonical was in that business.
As for why OEMs don’t do it more, or why they don’t do it instead of paying for Windows licences: custom dev, testing and certification for each model variant is a significant cost. Even if the OEM saves that money of Windows licences, the market mostly demands Windows.
System76 is a company that produces laptops and desktops with their own custom Ubuntu variant, if you want to see an example of one company going the full Linux route.
Percentage cut? I think the better title would be Patreon for Open Source (which is also itself used for Open Source, e.g. Vue.js). Seems like a huge win for Tidelift.
The one thing I dislike about Patreon (which I notified them about as well) is that I need a subscription for everything. Say I have a few dollar of disposable income I just want to donate to opensource indiscriminately I need to make a choice of which. And there are only so many levels (each with a baseline) in Patreon that a lot of smaller projects get left out.
I would like to have just one amount per month that gets withdrawn that I don't have to think about any further. And that just gets distributed over projects. With the idea that a lot of micro payments make more than a few big payments.
I preferred Flattr's model - you just donated a fixed amount per month, and they divided it by project. But it wasn't indiscriminate - you had to click on a button for each project. Now it seems they use a "smart, privacy-friendly algorithm [which] measures attention on websites", which is a no-go for me.
The problem with indiscriminate is that there are many, many, many OS projects out there. You need some curation, and that opens a can of worms. Maybe they could allow people to share and use lists?
Flattr's model seems really well suited for conveniently contribution back to open source. Does Flattr not work for software anymore? I'm trying to figure out why it's not more popular as a way to contribute to open source software.
I'd be happy to chuck some cash at free software. Things like Emacs are far more valuable to me than software I've actually paid for. I know a few developers are on Patreon but that requires figuring out who deserves it the most or a fair bit of admin to spread out payments. Maybe the FSF or someone could distribute cash but they don't seem very interested.
A crucial difference from Patreon is that this is a commercial service (an enterprise maintenance subscription). Participating maintainers help do the work behind it, and subscribers who buy it receive benefits for their money.
This is complementary to and different from a donation model.
I work on a product that uses Buildroot, which doesn't really act like a "package manager" in the sense that libraries.io seems to want. We also have a handful of FOSS projects that are just copied into our tree and applied on top of the base system. Is there any anticipation of support for that kind of situation?
I think there's a clear mapping of the Tidelift model to this, and there's also some customer demand from people building embedded systems.
As a practical matter it's a bit different from what we built first, both in terms of what customers are looking for / who the customers are, and in terms of the technical details of how we'd analyze dependencies. So we don't have support for it yet. But I would like to figure it out when we have enough team bandwidth.
A lot of open source software is written by company employees on company time. I suspect most projects that are most useful to most companies are built and maintained that way.
This is very true, and somehow I'm not that surprised to find this comment near the bottom of the discussion... seems that many people don't realize it, including HN readers!
I'll put this on the list of things to keep an eye on. I have dedicated a fair bit of time to an open source project I started a few months ago. I have no idea if it will ever make me money but I'm hoping to at least be able to pay for server fees through donations. My current plan is to go with patreon and I'll see how that will work out.
Maybe also look into https://licensezero.com. Even if you don't like the licenses (I think they are good), there are lots of interested articles in the blog.
I'm honestly confused, would love someone to explain:
From Wired: "Tidelift doesn't offer technical support"
From Tidelift site: "The professional support you need."
So, which is it?
From Wired: "[Tidelift] doesn't employ the developers who maintain open source projects."
From Wired: "[D]evelopers can focus on code instead of sales and marketing."
If they aren't employees, what are they? Contractors? I can see how it simplifies things to have to deal with 1 party instead of N, but if they aren't paying you a full salary it seems like a developer would still need to deal with sales and marketing.
The issue here is that "support" is an overloaded word. Tidelift does not ask maintainers to be a help desk where subscribers can call them up directly. But we do provide certain assurances and help with open source dependencies, through a combination of our own efforts and that of participating maintainers.
It's not that developers don't have to think about sales and marketing _at all_, but it's much reduced vs. starting one's own company from scratch. All those jobs that sales, marketing, finance, operations, etc. are normally doing at a company are things that Tidelift takes on.
From what I've gathered, the developers don't work for Tidelift in any capacity, Tidelift just collects money on their behalf whether they want it or not. If you agree to Tidelift's terms, you get a portion of the money they collected. I still don't see how they're helping open-source developers though. They keep saying that it'll be easier for big corporations to have a single place to pay, but they're going to take a huge chunk of the money for themselves instead of giving it to the developers, and the amount the developers get is based on some secret formula. I really don't see how this benefits anyone except themselves and big corporations wanting to say that they're helping OSS, but not really caring where the money goes.
I would say that we collect money on behalf of the companies who buy an enterprise maintenance subscription from us, and we agree to provide those maintenance services. So far this is what many OSS businesses do.
But while existing OSS businesses hire 100% their own staff to then provide the service, we split our revenue with interested maintainers who want to help provide the service. We are creating an opportunity for upstream projects to participate directly _if they want to_. If they don't want to, then no problem!
The beneficiaries are: subscribing companies get an enterprise maintenance service for their dependencies; participating maintainers get paid a revenue share (royalty-style model) for doing work on their project.
Tidelift's share of revenue mostly is not profit. It's analogous to what any software vendor would pay for the nontechnical roles at the company. https://tidelift.com/docs/lifting/paying goes into more detail on that.
It is worth spending money on sales, because even though it lowers the _percentage_ of revenue going to engineering, it increases the _amount_ of revenue going to engineering. Businesses spend money on sales/marketing/finance/ops because it results in more money overall. The same math applies to Tidelift.
All other open source vendors give maintainers a 0% cut, though the best ones do add a lot of "in kind" value in the form of contributions, those contributions often actually create more work for the primary maintainers, and everyone ends up bottlenecking on those overworked maintainers.
Tidelift is not a money transfer or donation system. It's a commercial service provided in cooperation with interested upstream projects.
Would be cooler to have an open source/license framework for handling payment processing, easy industry wide contract templates: why not make a X,Y,Z (like MIT, BSD for licenses) thing for contracts with open source vendors AND then if the open source developer does not want to handle all this stuff himself give him the opportunity to choose a service like tidelift with a certain percentage cut.
For large companies to buy something, there's considerable overhead: legal review, finance review, management, budget, etc.
That's _after_ someone at the company has figured out what the product is and that it makes sense to buy.
We wouldn't want all of this overhead involved every time a developer adds a new package to an app. And if it were involved for all the thousands of deps most teams have these days, there would be a whole second team just managing the purchases.
As a practical matter, software teams need to buy dozens rather than thousands of products.
By grouping a lot of packages together, Tidelift lets those thousand transitive dependencies benefit, while previously only the largest high-profile projects had a chance.
This reality (that buying stuff has a lot of friction) also explains why Tidelift builds "fund a sales team" into the model.
Why should I as OSS maintainer give a cut to Tidelift and even let my revenue be solely dependent on their algorithm when I could just put a onliner in my project stating that usage for other OSS is free and commercial users need to buy a license with a link to an online payment page where I control price, duration, etc.?
Because selling stuff requires more effort than just "here's my price, pay me".
By doing that, you've put your code into the realm of "commercial software", which engages with companies/corporate use in a whole different modality. If you've never sold software to a business, you will have no idea how much is involved in this side of things.
In addition to being treated differently by your potential customers, you will also earn the hatred and ire of your open-source-loving colleagues. Some bored college kid will see your dual-licensed software as an immoral act, and spend time building a less-awesome and more incomplete "completely free" version, which will then attract dev mindshare and users and eventually ossify into a de facto standard which you will then have to support.
That college kid will one day graduate, and think he can build a business on top of this amazing software he's made that everyone loves and wants to use, and then sit around trying to figure out how to make money from it. He may even consider making a "free-mium" model or an "enterprise" offering on top of the "open core" of his widely adopted OSS.
These will most likely fail, because - again - SELLING THINGS IS HARD.
Then you and this college kid who disrupted your dual-licensed OSS will one day meet at a symposium for "open source sustainability". It will be awkward. Teeth will be gnashed. You will get lectured about not having just used Patreon. Meanwhile the companies that use your and the college kid's OSS continue to hit their quarterly numbers for Wall Street. Executives earn out bonuses. The circle of life continues.
This "charge for commercial use" model was tried -- shareware -- and was an economic failure. It's advocated against by most organizations, like FSF and Creative Commons.
At most you see a "this is GPL but I wrote it so I'll give you a license to not follow the GPL for my code". Which is a quite different thing.
Setting up a payment page and writing one line to the license, even if I outsource that one time effort, will be indefinitely cheaper than having my revenue at the mercy of some random algorithm which doesn't even take into account how important my software might be to a company and giving a huge cut to a third party which really doesn't do anything other than profiting of my hard work. I struggle to see the appeal for OSS maintainers.
For one thing, Open Source software can't require commercial users to pay. The common way is AGPL then, in the assumption that it's unacceptable for companies to comply with, and selling a different license too. It's also a hurdle to take that someone makes a decision to pay for your thing specifically (and doesn't go search for a free replacement). Lots of still quite valuable components don't really meet that hurdle, and you severely limit your adoption by using e.g. AGPL. If (and that's a large if) tidelift gets somewhat widely adopted, it'd trickle down to all parts of the ecosystem, not just the few standout pieces being able to get paid otherwise.
> Unlike Red Hat, Tidelift doesn't offer technical support,
And that s why it is probably a failed model. On the other hand, they could offer open source tech support, or pay people to do tech support gigs, or perhaps give developers a way to make money by tech supporting their own open source product.
They're trying to create a new marketplace where commercial users of OSS can actually give money back to FOSS devs.
Many FOSS devs live a life of poverty because they have no idea how to actually sell things of value around their free artifacts and free labor. It turns out that selling stuff is hard, in general, and feels almost nothing like coding. ¯\_(ツ)_/¯
It sounds like the developers make some sort of “promise” to maintain the software. Not really sure how that’s enforced or what even constitutes regular maintenance. I doubt anyone is committing to an SLA for fixes for the relatively paltry sums mentioned in the article (at least $10K over two years).
It’s an interesting idea but it sounds like it lacks anything that really binds the developer to a level of service. Plus the pay isn’t “quit your day job”-good so ya know, that day job is gonna take priority. My gut reaction is that it sounds like an easy way for companies to pay a sum that lets them feel less guilty about freeloading off someone else’s work, and if the developer is more responsive to their requests, hey, bonus.
Correction: I appear to have misread some of sales copy to potential subscribers, there is no promise of individual support involved, just continued maintenance.
--
Even that "far from quitting your dayjob" amount of money could in theory impact a lot of "do I keep maintaining that lib a younger version of myself once built?" decisions. If that was the only thing tidelift promised paying companies, protects that get donations are less likely to get abandoned, it would kind of make sense. But in their sales copy, they are actually selling services (no: see correction above) provided by "lifted" maintainers, and that's where it stops being funny, for all sides involved (except tidelift). I wonder if the terminolocal proximity to "shoplift" ever occurred in their investor talks...
If they ever make it to the point of regular payouts, there will likely be some hidden scene of opportunists rushing to get recognised as the maintainer of as many abandoned - or just stabilized to the point of nondevelopment - packages as possible. Kind of like the alleged scooter-charging fights (no idea wether those are real or just news-fiction), perhaps something good could come out of that nonetheless? (maintainership-hoarders actually ending up doing some maintenance)
I think the idea is the more companies that sign up the more money can be given to a particular project and over time allow those people to go full time on their project. But since it’s new with little to no customers they are relying on capital to pay some developers guaranteed 10k over 2 years. Over this 2 years this could catch on and pay a lot more than 10k.
Correction: I appear to have misread some of sales copy to potential subscribers, there is no promise of individual support involved, just continued maintenance.
--
Tidelift is promising them the stars about services while not being involved at all in their fulfilment (no: see chevron above), except for maybe threatening to kick out their "lifted" projects if they don't deliver. (or maybe even sue whoever pressed "lift your package"?)
The more benign interpretation, as in a peer comment, is "allow me to donate without figuring out the distribution myself". That sounds perfectly reasonable, but it would be much more convincing if they had less promises in their pitch to subscribers and a "pay as you like" option (here's n $, please figure out the appropriate distribution for me while taking your cut").
Also, with the well established "failure or unbounded financial success" model of VC funding, how could one ever expect tidelift to not eventually abuse their position by taking seen ever higher cut? Maybe if it was a bootstrapped business, one could reasonably hope for a promise of only taking what is needed to be held up, but anything with actual investors needs a more formal arrangement. Maybe a charity/coop/nonprofit/foundation with clearly defined and enforceable bylaws that transparently buys implementation, operation and services from an associated for-profit might do, but "trust us, we have cute toddlers and pets" just isn't enough.
For me it would be the convenience of not having to choose which project I do and do not donate to (as each project has a baseline donation amount (even $1) to make it cost-effective (ie: paypal fees), so I have to make a choice to divide the amount I'm willing to donate each month.
I can thus dispose some money each month and feel that I'm donating (even if it's just a few cent) to every project I use. If more people find this easy, a lot of small donations will make a big one.
