hp

Just wanted to add here for those interested in this kind of thing, that we have over 4000 packages with income maintainers can claim today on Tidelift.

If you're a maintainer, ctrl-f through this list and see if you're in there: https://blog.tidelift.com/is-your-package-eligible-for-incom...

Tidelift is also supported via the new GitHub Sponsors feature: https://tidelift.com/subscription/how-to-connect-tidelift-wi...

If you aren't in the 4000+ packages we have income for now, you can still sign up (which helps us get to subscribers who are specifically using your stuff, meaning income in the future).

I'd argue that money's been in OSS since its inception.

To try to put a number on it, here's a random study that 50% of oss is people at their paid job: https://dirkriehle.com/2013/08/22/paid-vs-volunteer-work-in-...

But anecdotally that number is consistent with my experience.

When we created the GNOME Foundation in 2000, it was in part to manage the commercial vendors and money involved (Compaq, Eazel, Helix Code, IBM, Sun Microsystems and VA Linux Systems, see the press release https://www.gnome.org/press/2000/08/red-hat-joins-industry-v...).

This was not at all unique to GNOME, same kinda stuff around all the major projects at that time.

One thing I think is new and constructive is more ways to pay maintainers without asking them to join a giant company.

As someone who was around 10 years ago I'd question that a little, there were lots of OSS companies then, and lots of people getting hired and paid to work on OSS too.

A difference today is trying to move some of the money down to smaller-scale projects that have little chance of becoming a standalone company, and also more options to get paid without having to go work at a big company.

I think the people who really care most are doing ops not dev

(though of course many people do both)

People have tried every point on the JSON-to-full-programming-language spectrum, I put some examples in this post: https://blog.ometer.com/2015/09/07/json-like-config-a-spectr...

JSON5 is new since that was written I think... there are a bunch more of them too.

As part of the team at lightbend that came up with HOCON I still like it because it lets you use env variables (handy for Docker, Heroku, etc) and has some don’t-repeat-yourself capability without going to a full programming language.

(If you’re going full language, to me why not use a real one, maybe the one your app is written in... but there are definite tradeoffs to using a language, like difficulty writing automation that understands the config, and it assumes anyone changing config is a full-blown developer)

The point here of course isn’t that it’s bad to make a profit with OSS; it’s that maintainers can learn from how this was done and participate in it themselves to sustain their work.

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.

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.

Maintainers who sign up are contractors (here is the contract: https://tidelift.com/docs/lifting/agreement ).

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.

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.

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:

* https://tidelift.com/about/lifter * https://tidelift.com/docs/lifting/tasks-overview * https://tidelift.com/docs/lifting/agreement

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!

The open source part of our implementation is here: https://github.com/librariesio/libraries.io https://github.com/librariesio/bibliothecary

Our ideal is that if a subscriber is using it, we can sign up its maintainer. The Tidelift platform is built on an OSS project called libraries.io which supports many package managers: https://libraries.io/platforms Here's what's involved in adding more: https://github.com/librariesio/libraries.io/blob/master/docs...

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.

Here's an interesting article from patio11 on enterprise sales and purchasing: https://training.kalzumeus.com/newsletters/archive/enterpris...

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.

No. https://tidelift.com/docs/lifting/paying has the long answer to that.

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.

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.

That exists but it's a different, not-mutually-exclusive thing. The Tidelift Subscription is not a donation tool or money-transfer mechanism, it's a product - produced in collaboration with interested upstream maintainers.

Tidelift co-founder here, thanks everyone for the interest.

I've added a discussion of Tidelift's share to the docs at https://tidelift.com/docs/lifting/paying TLDR our commitment is to pay out at least 50%.

What we're doing at Tidelift is an enterprise software product (analogous to something like Red Hat Enterprise Linux), but a difference is that instead of hiring a bunch of people to repackage upstream projects, we're offering upstream maintainers the _option_ to participate directly by helping us do the work - for a revenue share, rather than a flat fee.

The app store analogy isn't quite right; an app store provides a catalog and some review services, but much of their 30% rake is profit as far as I know. The Tidelift share includes funding all the non-engineering parts of an enterprise software business, including a crucial one, a sales team.

The point of this is to make the pie larger. We want to pay the maintainers (at least) 50% of a lot of money, instead of 90% of a little money.

btw there are a number of options out there to make straight donations to projects and we support those! That isn't mutually exclusive with what we're doing here and in fact many of our participating maintainers also take donations.

The payments are not a donation, they are earned by helping provide the Tidelift Subscription service (the set of tasks and responsibilities enumerated at https://tidelift.com/docs/lifting/tasks-overview ). If someone earns the money it's theirs and they can send it anywhere they want, charities for sure are an option.

Hi from Tidelift - thought I'd share a quick tour of what we have to check out today.

We think we can get to a more sustainable model for open source software, by adapting the traditional commercial subscription model to include upstream projects.

The original link above is a discussion of the subscription itself: https://blog.tidelift.com/announcing-the-tidelift-subscripti...

Here's a tour of our free dependency analysis service: https://blog.tidelift.com/want-to-better-understand-your-cur...

And for open source maintainers, maybe most important is the page about how to get involved, see https://tidelift.com/about/lifter and in particular click through to "Download the lifter guide" at the bottom, that's the long version of the details.

Would love to hear your ideas and feedback. Thanks!

Linux distributions have been including the major version in the name for a long time; when we started doing this at Red Hat I wrote down the rationale at http://ometer.com/parallel.html in order to convince upstream projects to do this upstream, as many now do.

For non-system package managers like npm, always using a lockfile is the best current option IMO, for those package managers that support it. https://blog.ometer.com/2017/01/10/dear-package-managers-dep...

It isn't better than those categorically. But it's definitely better than them for building a multi-process desktop.

"better" depends on what you are trying to do.

Of course CORBA and SOAP are considered old and horrible now, 15 years later. But currently-popular stuff is in many ways equally unsuited to coordination of local desktop processes, because it's not designed for that.

yep. as noted in https://news.ycombinator.com/item?id=8648995 it wasn't even just dcop - KDE had tried CORBA before switching to DCOP, and GNOME of course tried CORBA (two different ORBs), then tried Bonobo-on-top-of-CORBA, and SOAP. There were tons of documented protocols on top of X11 (many still in use today). And that's ignoring the countless ad-hoc solutions that various apps used...

Linux desktops are implemented as process swarms and communication among processes is one of the central things they have to deal with.

right, nobody was ever intended to use the raw protocol details directly... those details were intended to support an API that looked like using in-process objects (well, perhaps in-process objects with methods declared as 'async').

> There is a reason there is no "shared bus" in Internet communications.

Yes, but dbus isn't _for_ Internet communications. It was designed to wire together the multiple processes that act more-or-less as a whole to implement a desktop environment.

"Better" is contextual. The main problems dbus solves aren't "IPC" at all - they are things like lifecycle tracking, service discovery, and getting events across the system/user-session security boundary.

dbus-broker looks interesting!

something has to matter :-) after making commas, braces, brackets, and quotes optional linebreaks were what's left...

re: other languages: yes, there's a list of implementations in the typesafe config README

I'm pretty sure the last value wins, but maybe don't understand what you mean.

I would say HOCON isn't JSON for humans, it's config file for humans. The features are all about building up a config in a DRY way and merging overrides with defaults and overriding with env vars and stuff like that. It's specifically for the config use case.

JSON superset is a bonus feature which is useful if you don't want to learn new syntax or want to machine-generate part of your config.