Give away your code, but never your time | Hacker News Reader

Give away your code, but never your time

wgross.net

430 pointsbrakmic222 comments

Color me deeply skeptical of the suggestion to try to lock people out of community participation unless they pay.

The real secret to not burning out is to scale up the set of maintainers in proportion to the users. You do that by lowering the barriers to involvement, not raising them.

Most maintainers err on the side of controlling too much. Which makes them into bottlenecks.

One or two good PRs is enough for me to give you commit bit on my repos. This has never yet resulted in abuse, and has brought in a many helpful co-maintainers.

Bad commits can be easily reverted. Whereas giving people a bit of trust often inspires them to help more.

Absolutely this.

This applies to engineering at software companies as well.

I completely agree, the only thing I still like to keep to myself (or to a very select group) is the ability to cut a release.

If you want commit access, just ask. But I still want to validate releases that get pushed out to a bunch of people.

My policy is to never ask, and to only accept if I think I can be worthy of the work at the time (so I might accept at a later date if I feel I don't have the bandwidth today).

And I tend to try and offer if i start to notice the name in a few issues or PRs.

Bad commits are the absolute most difficult thing to reverse when they get released and the userbase codes to them. When I don't pay super close attention to what's being contributed, it creates three times as much work after I let it through.

Superficially, that sounds more like a release process issue than a bad commit issue.

How often is commit bad enough to require revert, yet made it through testing and got released?

Code style, inconsistent APIs, a feature that's barely tested by its own contributor, introducing dependencies on innards that were planned to be removed by an ongoing refactoring project, etc. So many ways contributions can go wrong.

All those things should and hopefully would have been caught when the PR was made, not after the commits made it into master.

The entire context of this thread is that adding committers can introduce risk in the quality of accepted contributions. Building a trusted network of gatekeepers is hard.

Just because stuff gets to master doesn't mean they get to the release.

> Code style

How is that an issue in this day and age? Just run astyle or indent.

> Just run astyle or indent.

"Style" is more than indentation - my favourite example is something I worked with very closely, but always needed a cheat-sheet on my desk - the PHP arrays api.

Just look at the docs for array_search and array_replace.

This is much worse in managed memory languages - do you allocate memory, who frees it, who can use a buffer in zero-copy mode, who can't ... whether the functions are always re-entrant.

All that said - any originating coder who burns out due to support issues, killing the community is measurably worse off than someone who has thousands of users who demand that you support such "legacy" APIs for another six months.

I'm talking here about a developer API that is extremely flexible and extensible. Even one-liner contributions can have bad effects, and virtually all contributions I receive "work" at a superficial level and if they provide tests the tests usually pass. "made it through testing" is a low bar, the bigger implications of a patch need to be considered.

Examples of PRs that "work" exactly as intended yet are the wrong way to solve the problem:

https://github.com/zzzeek/sqlalchemy/pull/381

https://github.com/zzzeek/sqlalchemy/pull/382

Here's a large PR:

https://github.com/zzzeek/sqlalchemy/pull/365

that after lots and lots of back and forth I finally merged with lots of edits from me at: https://github.com/zzzeek/sqlalchemy/commit/7d3da6f850dca54b...

...aannnnndddd - after all that work and testing, it was wrong! Fortunately someone caught the mistake within the beta release:

https://bitbucket.org/zzzeek/sqlalchemy/issues/4072/mysqldml...

if I had released that fully and the whole world coded to "mysql.insert.values.bar == 5", that's broken API since it breaks the values() method. Backwards-incompatible fix required.

Do you think that's generally true? Or is it a facet of your experience running three of the most important Python packages around?

> One or two good PRs is enough for me to give you commit bit on my repos. This has never yet resulted in abuse, and has brought in a many helpful co-maintainers.

In addition, I find it's helpful to identify the really keen contributors and ask them privately see if they want to take on more responsibilities.

"a bit of trust" this! Most often maintainers ego is the issue and too much control over ones baby project is the road to frustration and burnout. The way the power is shared and the shape of community structure is huge factor often neglected by tech-only focused maintainers/owners. There is a good piece of wisdom on social aspect of open-source in Social Architecture by Pieter Hintjens[0]. I recommend learning about his pov to anyone interested in open-source open-projects.

[0] https://www.gitbook.com/book/hintjens/social-architecture/de...

Excellent read! Thanks!

A gitlab feature I miss on Github is "protected branches" and being able to add contributors that can only push to unprotected branches. This way you can give people access to the main repo while still being able to check code before it goes into master

You can do this on Github with custom hooks etc. But yes.

That's potentially one way of doing it but Github does also have a specific feature for doing this literally called "Protected branches":

https://github.com/blog/2051-protected-branches-and-required...

You can do this now. $work uses github and has it so that a bit of code has to have be reviewed before it can be merged to master.

You can do this on Github. It's even called the same. Go to your repo -> settings -> branches and it's the 2nd item (Protected branched).

I use this feature at work so I can confirm it behaves as expected.

Oh, great! I tried it a while ago and the setting was nowhere to be found!

The Pull Request Hack | https://news.ycombinator.com/item?id=5357417 (March 2013)

http://felixge.de/2013/03/11/the-pull-request-hack.html

> Whenever somebody sends you a pull request, give them commit access to your project.

I agree with requiring more accountability before granting the ability to create official releases.

> Most maintainers err on the side of controlling too much.

Burnout can happen by working too much. It can also happen by too many discussions/politics if you give out commit rights like cookies.

We kind of did this with a project I was working on once. Someone was being helpful, main maintainer was getting tired, so helpful guy got full rights to the repo. He went on a several-year-long frenzy of activity, up to being a release manager, putting lots of micro-optimisations into the code and still being generally helpful until he got sucked up by Google and vanished.

Sadly, lots and lots of little bugs and awkward design decisions crept through. Obscure ones, hard to find, and a coding style that tended towards obfuscation. Guy had a habit for assemblyish/fortranish code.

I think the lesson learned is, sure, maybe give the helpful guy full access, but still keep your eye on them and encourage everyone else to do so too.

> main maintainer was getting tired

Would the project have had much development at all without the "helpful guy"? If the maintainer was too tired to even keep an eye on him/her, then it sounds like the project would have stalled without that help.

> We also need to bury the idea that any developer who submits an issue or pull request is automatically entitled to the attention of a maintainer.

> The message to users should be “do whatever you want with the code, but pay us for our time if you want to influence the project’s future.”

So, for me, this goes against the reasons I decide to give my personal time to the community. For me, creating an open source project is a contract with the community, and part of that contract is to assist members of this community that might require features or have issues. Statements such as the ones quoted above go wholeheartedly against my idea of an open source community, and I have a feeling most of the open source community shares this sentiment.

Breaking this contract would be, for me, a cease and desist of the project. For me, it is very simple, if a personal project is stagnated, that’s acceptable as no one owes anyone here anything. If a company’s open source projects go stagnant, but the company continues to boast how pro-OSS they are, it is a cardinal sin, as they have broken this contract with their users. This may be a naive look, but I don’t think a company should be able to have it both ways—boast about its OSS projects, lure people in and then ignore them and move on to their next PR OSS project.

Donations are a different proposition than the suggestions in the article, and should definitely be encouraged.

The issue is donations don't work even if you have a large user base.

This this this. If you provide a service for free, the vast majority of your user base will never care about giving you money, and will just stop using your service and find another one if you try to start charging them for it instead of keeping it free. One of my side-projects has ended up here and it's been a huge pain to deal with.

We are not talking about a service here, we are talking about OSS codebase and in my experience it does work.

What's your experience?

In my experience, i donate to projects, which i use often/or build upon.

That's nice of you. Is it enough to keep the projects alive?

My data point would be Borg Backup, which, if you were to consider Bountysource to be payment for development, is under-financed by perhaps a factor of 40. 80+ % of funding came from three organizations.

And what I've heard from other maintainers is that Borg seems to do comparatively well.

So no, if you think in terms of payment, donations do not work in the open source ecosystem.

> We are not talking about a service here, we are talking about OSS codebase

IMVHO, these are the same thing for the purpose of this discussion -- providing something to others, free of charge.

> and in my experience it does work.

Good for you (no sarcasm meant). But sadly this doesn't really seem to 'scale' that well.

That's a strange view of open source that borders on communism.

You don't have any duties or obligation towards any individual to assist them with their issues.

The only obligations you have is to be honest about the project. For example, if you know that the project is not written with security in mind, you must announce the fact, so that people don't go using the project assuming you took care of all potential exploits.

Beyond that, you have no obligations towards anyone. Quite the opposite. You've already done your part. You donated the product of your effort for free. The obligation is on people who use your product. If they want you to care of their issues, they are obliged to give something back in return. At the very least, appreciation.

Don't know about duty but I think everyone has a right to expect help and a right to give help. It makes for a better world where these rights are regularly exercised.

> I think everyone has a right to expect help

Of the people with whom you have formed strong social bonds, yes.

Of random strangers? .. I don't think so.

Unless they are bound by some sort of a contract (employees, servants, etc).

> everyone has a right to expect help and a right to give help

This might make sense when asking a stranger for directions or for someone to help with your car problem, because the relationship is 1:1.

But this breaks down in contexts where scale is a factor.

When assisting users of your project, the relationship is 1:many. And if the project is popular, it is unfair to expect the author to be helping so many people.

I don't really see how 1:to many makes any difference in principle. Perhaps you were thinking of the amount of effort to help the many? As in 1:1 case it is up to the helper to decide how many resources, if any, to spend on helping. A society where the default position is that people deserve help is different from one that is based on the survival of the fittest.

Even if the default position is to help, it can't be unconditional, there are limits. You don't have a right to expect help when it places an unreasonable burden on the helper.

I upvoted you because I think it's an interesting position, but you should realize that adding duties will discourage people from doing any contributions at all. It starts to feel like a case of "no good deed going unpunished".

I wasn't thinking of legal rights and obligations but rather of a moral ethos.

The alternative brought to it's logical conclusion is Shkreli and rasing medicine prices by thousand percent.

The alternative to giving away your personal time for free to an open-source project is gouging people on vital medication? That doesn't seem true in any sense.

A right to "expect" is a right to control your own though, unless you mean something else?

I don’t get where communism comes from. This is my view on personal responsibility and nothing more, and I naively expect people to have similar dedication to open source software as me. I understand this is not always the case, but I have described the perfect world as I see it in my comment above.

I'd like to second this:

> to be honest about the project

Sometimes you see the attitude "You get what you pay for", but putting code in the ecosystem without property explaining what it is is like littering.

In the same way I want to be able to walk in the park without constantly checking the ground for dog shit, I want to be able to use software without having to audit every part personally because the author didn't care for it, or communicate that fact.

* I mean didn't care for security

edit: This down-voted too? The clarification?

I really like and appreciate the notion that a project could/should state what the assumptions are, where applicable. And, perhaps point out weak spots that could be important to users. If nothing else, it sets the expectations right.

The perfect example is yours, "this project does not take security into consideration. Use at your own responsibility. You should probably start with securing this_X, that_Y, and that_Z.".

Another example could be "this is a POC and does not go kindly on system resources. You might want to scale back the number of simultaneously opened sockets for any real use."

> creating an open source project is a contract with the community, and part of that contract is to assist members of this community

I disagree. Creating an open source project is a gift to the community.

Expecting further time and attention from somebody who gave you a gift, out of a sense of entitlement from having received the gift, is just being rude.

Pay for my time and I'll help you with your issues. Demand my time because you're somehow my "community" and I'll just re-explain the above.

That statement is made by how I view my open source projects, and thus what I expect from other open source projects. Could be that my expectations are too high, but I don’t believe so. This is not entitlement, it’s expecting a level of seriousness similar to that I am willing to give.

A community that hasn't established a semaphore for updating the code isn't a community. It is hard to build that with consensus instead of input from its creator.

The nature of what succeeds in opensource has everything to do with whether the creator puts community work in themselves, nominates someone, or just publishes read-only code.

Naturally, anyone is free to do whatever they like.. but most people seem to expect a result from their actions and publishing pure code is rarely going to have any result.

Whether you want give support and maintain the project or just throw the code, it's important to make it clear so people can have reasonable expectations. Also if you want provide paid support, make it clear too.

I've recently saw a license that make the author intentions of not giving support clear: DILLIGASPL (Do I Look Like I Give A Shit Public License)[1]. Sounds like a joke, but it's a way to show what are you up for.

https://github.com/samlev/DILLIGASPL

> creating an open source project is a contract with the community, and part of that contract is to assist members of this community that might require features or have issues.

If this were strictly enforced, there would be much fewer open source projects, as not all authors would be able to meet the obligations.

Then add a disclaimer that the repository is not actively maintained and is looking for maintainers. This will absolve the responsibility of the entity that can no longer sustain the project and set the expectations of visitors accordingly.

There are some areas where fewer projects would be a good think. There is a burden of choice that can be solved by filtering for authors ready and willing to meet more requirements.

I led a small open source project more than a decade ago.

Most people involved had more time than money. I'm quite certain that trying to charge an annual fee from members would have killed the entire project before it was even born.

Introducing money to the equation changes everything. People start to look at the project as a product they are buying, instead of a cause they are contributing to.

I believe the author of this article is deeply misguided. Money is not a way to make open projects work, but it is a good way to kill them.

As soon as money is involved there is a certain expectation of quality and the work being done properly. If you start depending on that money then you are under the control of your customers and your hobby will quickly degrade into a regular job.

"Degrade"? Getting a job contributing to FOSS projects sounds pretty good to me.

Depends, turning a hobby into work can be either wonderful or horrible.

As much as I agree with the sentiment behind this post, I disagree with the implementation. The nature of open source code is collaboration. Paying for collaboration seems like it would hinder progress altogether and possibly direct the project into a direction that is not suitable for the poor majority not paying. One more thing that bothers me is that money for maintenance should not come from developers. This is like robbing Peter to pay Paul.

Disclaimer: I am the CEO of Code Sponsor (https://codesponsor.io)

Code Sponsor is trying to help provide those who are maintaining OSS projects with untethered sponsorship funds. They can go about doing their business on the projects and be making money through sponsor-based ad revenue. This provides them with the incentive and finances to justify continued support on those projects that end up being abandoned when unfunded.

I agree that this is a HUGE problem that needs to be addressed. Code Sponsor's approach is to go where money can scale: marketing budgets.

I've seen these kinds of things and have always been dubious that they are able to pay a full time salary for someone that is even close to what they could make with a normal full time dev job. What's the highest monthly amount your company pays a dev? What's the average and median?

Most of those using Code Sponsor are very new. I can tell you that so far this month (Sept 11) we are payout out $511 USD to developers. Last month we paid one developer over $130. It's not life changing, but it's excellent supplemental income.

You're likely going to be shut down by GitHub. They have a special section in their ToS that prohibits advertising.

https://help.github.com/articles/github-terms-of-service/#k-...

> Short version: We do not generally prohibit use of GitHub for advertising. However, we expect our users to follow certain limitations, so GitHub does not become a spam haven. No one wants that.

>They have a special section in their ToS that prohibits advertising

Ehm, your quote does not quite support your statement:

>We do not generally prohibit use of GitHub for advertising

It's a TOS, worded for PR, besides which it's unenforceable and at the whim of GitHub.

It's like building a business on Google Reader or FB Parse.

We have advocates at GitHub and are in discussions with their compliance team. Code Sponsor is not directly tied to GitHub for it to be successful. Many of our developers are making money through different channels such as npm or their own generated documentation website.

Even though GitHub may say we cannot do this on their website, it does not prevent developers from generate a healthy side income building OSS.

Here's a blog post we just released which includes links to different developer repos and sites (aside from GitHub) https://medium.com/@codesponsor/fighting-for-open-source-sus...

Devil's advocate: How about an issue/PR tracker that lets users pay for priority? A simple bidding system. If BigCorp International is willing to pay $200/hour for IE10 support, they can be next on your list. And afterward, an bug with significant community support totalling $50/hour, pledged by 50 different users. With allowances for your own preferences as maintainer and the needs of the community, of course, but giving people who care the most the opportunity to put their money where their pain is.

Something like this could work, but I worry that it would create competitiveness and animosity among users.

This is the point of having a seperate buisness license. Sell to big companies along with support.

I think the point was to have a one time option limited to the scope of work instead of yet another subscription model that tries to pay for the work as a form of insurance.

Someone did that, back in 2003! It looks like its changed over time (and its security certificate is recently expired).

https://en.wikipedia.org/wiki/Bountysource

Bountysource is definitely still active, though not as utilised as it should be. The cert expiring is obviously dodgy but it's only expired by a few hours and assumedly will be fixed soon

Paying for PR? really? Why would anyone do that rather than maintain their own copy if it is an OSS project?

Maintaining your own fork means you are taking de-facto responsibility for the maintenance of more projects in addition to your paying projects.

The costs of keeping them current adds up surprisingly quickly.

In fact, it adds up so quickly that my company has a standing policy in place that we will do _whatever_it_takes_ to have any pull requests we need in an upstream project integrated in order to avoid us having to maintain a fork.

What this means in practice usually is that getting the pull request accepted becomes the primary focus for one of the senior engineers for the 1-2 weeks it takes to get it into a shape that the project maintainer can work with.

As you can imagine this is also expensive, but it's a fraction of the cost of maintaining our own fork of the project.

So - here's my offer to Libré, Free and Open Source Software maintainers everywhere:

I will _gladly_ pay the cost of 1 week of a senior engineer's salary to have you accept my pull request if you are prepared to either:

1) do the quality control work yourself or…

2) hold the hand of one of my junior engineers while they learn how to do it.

> I will _gladly_ pay the cost of 1 week of a senior engineer's salary to have you accept my pull request if you are prepared to either: > 1) do the quality control work yourself

I too would gladly pay one dollar for a hundred dollars bill.

When you consider the cost of having to re-merge all your work on every update, I'd be more than happy to pay some reasonable sum to have it merged into master and maintained there. Could save me a lot of work.

I built a site like this a few years ago, got absolutely no traction, and shut it down.

I'm very open to the possibility that I went about it the wrong way, but I don't really know what I should have done differently. Maybe it could have worked if I had done a lot more evangelizing -- I admittedly didn't do much, but what I did do was so poorly received that I gave up.

I think something like this has to be integrated directly into github or the project's issue tracker to have a chance to gain any traction. But honestly, even then, I'm not sure it would work.

vim has something like this: users who pay can vote on features to be added. https://vim.sourceforge.io/sponsor/faq.php

However, the donation is about helping poor children in Uganda, not about running the project.

I haven't seen any large scale, long-term open source projects succeed with a 'pay to play' process; what usually happens is the original maintainers realize that even with some amount of compensation, they still don't like scratching other people's itch when it comes to their project.

And then they realize that the amount of people/companies even willing to pay at all is a tiny fraction of 1% of their potential target market.

The better advice is to do what you want, know your limits, consider sharing some maintainance responsibility with another committer or two, and don't ever feel obligated to do anything with other people's issues and PRs. It's nice to do, but if it's interfering with anything else, or taking away valuable time, ignore them or just blanket close them, with a note that it's not something you'd be interested in maintaining.

The great thing about open source is someone can fork your code and do what they need. You have no obligation to help them, it's just nice if you can. And if they don't get that, that's not your problem.

It's not your problem only in the sense that it shouldn't be your problem. E.g., in theory.

Some people can be quite belligerent about their FOSS entitlement. I've also seen folk publicly bash open source projects just because the license wasn't permissive enough, in their opinion (GPL vs. their darling I'll-bend-over-do-what-you-will-with-me BSD or MIT).

It can be hard to maintain poker face with "not my problem"... as hard as the "fuck you, pay me" proposed by the OP. The social pressure to give away your work for free is real, and humans are social animals. Just look at this thread.

Sidekiq by Mike Perham is following the open core, paid subscription for a "pro" version containing extensions. His single founder company has a monthly recurring revenue in excess of $80k, as featured on Indie Hackers[1].

[1] https://www.indiehackers.com/businesses/sidekiq

I think what open source needs is some very deliberate price discrimination. Have the license be free to the vast majority of users, and cost money for large corporations that can damn well afford it. Not, like, large amounts of money, just something vaguely close to the all-in cost of one full time developer.

Basically, "BSD, unless you're a $1B+ valued company that is not paying our software foundation $10k/mo".

This is pretty much exactly how I feel about this issue. The contributors you really want are the youth that are young and ambitious, setting a price to contribute would hinder this growth. The contributors you probably don't want are the large corps who will try to push the project based on there income, charge them a lot for the privilege of dealing with their bias.

Many moons ago I developed a moderately successful shareware program. My licensing terms were simple: If you owned the computer where you installed and used it no license was needed, but if someone else owned the machine, you owed me money.

It allowed students, hobbyists and freelancers to use the software for free, for any purpose, but companies, institutions and governments had to pay to play.

This idea does not seem to translate in an obvious way to software released under an open source license.

I love the idea, but can't help wondering: did it actually convert into "sales"?

As I said, it was a moderately successful side business. I know of many cases in which the sale came from someone buying this on behalf of his employer years after he had first used the software as a student.

I was never after the nickles and dimes of users, always had my eyes in the deep pockets of major players. 99% of my sales came from multi-billion dollar corporations, universities and government.

Interesting idea, but two things struck me here:

1. Does that mean a student would have to pay to install it on their school computer? Or maybe a school provided laptop?

2. What about personal installs for other people? Not as a business or service, but merely on a friend or relative's computer?

Because in theory, both of those would come under 'someone else owning the machine', but they'd also be seen as personal usage by any rational person.

I agree with the first, but the second doesn't qualify. If the person using the software (a friend) owns the computer where the software is installed (my friend's computer) he qualifies for the free license. I don't think it matters who actually did the installation.

You'll always have a corner case or another. I wouldn't care about personal usage users.

Case 2 clearly falls into the free usage policy, but in case 1 if the school is requiring students to install this software in their school-provided hardware as a way of sidestepping licensing fees I think they are stretching it a bit.

The problem with this is if you are anything more than a small company, it's pretty hard to get authorisation and approval to pay for software.

A couple of years ago I was working for a UN organisation, and to get approval to upgrade our plan of an alerting tool from something like $10/mo to $25/mo required many people involved and weeks of time (not weeks of people time, but weeks from 'we want this' to 'ok'). For something new we would have to evaluate it against other competing products, and then it's just a waste of everyone's time, instead of 'gem install sidekiq'.

Admittedly not every company/organisation is this extreme, but once you get to a certain size most companies have something like this.

(I felt we paid our dues to the open source community as we open sourced a lot of our own in house tools and helped maintain a lot of other projects we regularly used)

The key suggestion:

"bury the idea that any developer who submits an issue or pull request is automatically entitled to the attention of a maintainer... If you’re the leader of one of these projects, charge an annual fee for community membership. Open source, closed community. The message to users should be “do whatever you want with the code, but pay us for our time if you want to influence the project’s future.” Lock non-paying users out of the forum and issue tracker, and ignore their emails."

Right, so are there any examples of successful projects which do this?

The idea is certainly plausible given that the vast majority of initial contributions to an open source project are based on need: http://climate-action.engin.umich.edu/figures/Rood_Library/S...

However continued involvement seems to be usually based on hobbyist motivations, so you might be setting yourself up to not see anybody else jump on board with you long term.

https://crystal-lang.org/sponsors/

I'm not sure how successful it is, but Crystal seems to have the right idea.

There's probably a compromise, but often non paying users do contribute in the form of bug reports and user feedback via the very same issue tracker that that they are to be locked out of. I also wander if paying entities have different objectives then non paying entities in such a way that paying entities will corrupt projects or alienate future contributors.

I dislike the key suggestion. What's the point of open-source - if not to give back? It's a developer's codex/morale to answer.

It seems the author is salty about the fact he doesn't make money from open source, but is investing a lot of time. Well my dear colleague, offer support to the bigger companies that use your software in production or use that software to sell another. Simple.

Open source was never meant to be for-profit, at least from my understanding. Something you give back to the community, because you have taken a lot from it in the first place. You dislike new issues by non-payees? Well, write better docs. Someone is also giving YOU time by submitting that issue or by finding a bug - so should you pay them money for testing? Be grateful.

Should we all pay for the open source tools/frameworks we use? I can guarantee this would cause riots. If you don't want to contribute to OSS don't, but please do not whine about it.

Your employer benefits financially from the open source community. People who purchase software cheaply due to lower barrier to entry and more competition also benefit. As a coder I generally don't benefit so don't feel the need to give back.

As a coder the tsunami of FOSS is a negative. My job is now to glue free modules together rather than design stuff. I'd be quite happy to pay for a compiler if I had to.

I mean if you are genius who has written all parts of OS/compiler/whatever software you use, then maybe it is a negative for you. But most people can't do so and FOSS is actually a blessing. If you like to pay for wall-gardens, where you can't read any code without an NDA/paying a million dollars, they exist. Feel free to use them.

I've been plenty happy working in Windows/.NET land. As a developer.

As a home tinkerer I do agree with you. And glad Haskell and Linux are available for free.

The benefits go both ways.

As a programmer that can work with FOSS software, you have now much more employment options because frameworks/etc. are not proprietary to the company you work for, and you easily transfer your knowledge to another company. If your job is "now to glue free modules together" you are also most likely responsible for a bigger part of the product due to FOSS, which could give you a better position in salary negotiations.

FOSS also gives (not just, but more so than others) developers better non-employment options. As a freelancer, you can more or less choose your software stack and then go hunting for clients, without having to worry about licencing fees limiting your client base. As a founder, you can much more cheaply found a tech-company, because there is much smaller upfront investment necessary, and when started as a side-project can be as cheap as renting a server.

I think a great architect knows when to use a battle-tested tool and when to roll-out his own. There is no shame in using something that has a great track record of not failing you. Building a blueprint is not about writing a new formula for a brick, but rather using the best brick on the market and focusing on making the building as usable and efficient as possible.

Honestly, I disagree with your statement. The tsunami of FOSS is sometimes an advantage as well, because people can easily migrate off of legacy architecture that they were hired to fix in the first place and pick one to our liking. Since I do not know your niche or how much experience you have, it's hard for me to guess whether you have worked as a contractor somewhere, but...

I had a guy re-inventing his own Celery with a single worker in the same thread as main process. Of course it failed spectacularly :) I then also had an example of someone deliberately not using already battle-tested auth libraries for social auth but creating his own and of course he managed to expose things that were not needed to the client app and the company got hacked. He spent a month building it, instead of just plugging in an already built library that is used in production by millions of people.

Another developer yet built his own framework which was never stable and costed the company tens of thousands of dollars for the three months it was in production (plus three for development).

These are not some small start-ups or dev-shops, but rather serious companies that had devs that were alumni of Big 4. I think I am not the only one with this experience.

For me that is heresy - similar to not using a great standard library in a any language, but rather building your own libs/wrappers. Now, I have nothing against modifying a library or optimizing it for your use case, however starting things from scratch is in my opinion a huge cost, unless your company has time and money to throw.

As a coder, it also means I don't have to code everything myself from scratch. Surely that's better than having to reinvent the wheel for every single project, especially where larger requirements like a full site CMS or framework are concerned. It also means new coders can join in without having to learn a new codebase for every role, that we're not paying a fortune for software licenses for every project and that we still have access to the source code to make improvements or have them rolled back into the original project.

If you feel it's better without those things, good on you. But I'm sure you'll find it harder to get help for a project than you would with open source, spend far longer on every project than you would by merely using an existing framework or end up at the whims at a large corporation with no interest in letting you make your own modifications to the code.

I'm sure you'll find it harder to get help for a project than you would with open source, spend far longer on every project than you would by merely using an existing framework or end up at the whims at a large corporation with no interest in letting you make your own modifications to the code.

If you're employed, why would you care? You're getting paid the same, the extra time is your employer's problem.

Well I guess it depends on whether your employer is simply paying by the hour or giving you a typical monthly/yearly wage. If its the latter, the company probably wants the project done as quickly as possible, not just whenever you feel it's 100% finished.

And I still stand by the 'easier to get help with' part. Unless you're the sole web developer or software engineer on a product, you're going to have to get someone else involved further down the line. If you use an existing piece of software, that's easy. Hire someone with experience in it, and they'll probably figure out what to do.

If it's bespoke, you'll need to either train them yourself to work on the software (and do the same every time someone new comes in), or hope they can figure out what your code is doing without any assistance. This will then take more time and effort every time someone gets hired.

If its the latter, the company probably wants the project done as quickly as possible, not just whenever you feel it's 100% finished.

Right, but if there was no OSS to use, it would be as quickly as possible.

And I still stand by the 'easier to get help with' part.

Right, but again, that extra time and effort is still the employer's problem.

The notion of charging people to be part of the community seems like a terrific way to immediately kill any semblance of community.

Realistically, the only people who will pay a membership fee are those who can charge it to a company. That means you'll lose all the people hacking on the project in their free time.

Personally, I contributed a lot more to open source when I was in college and had more free time than money. There's no way I would have paid to be able to contribute.

The solution is really just to have lower expectations on maintainers, both around timely responses/support (want fast support, pay for it) and improvements. They can and should also be more liberal with adding maintainers.

Are you sure? If what you're saying is true, wouldn't that mean it would be impossible for any business to have a "sense of community" around it?

To be part of a community you need to have the same stake as everyone else. Businesses don't have communities, they have customers.

A community can still be formed amongst your customers, and make your product better. Game mods are a good example.

No. The community around a business is their customers who dont contribute directly to the product itself, but to the general economy, knowledge and hype around it. You pay to buy the product and probably wouldnt work on it in behalf of the producer for free on your free time.

I shudder to think of the sense of entitlement some of my users would have towards getting me to fix their pet issues that they had to pay to tell me about. This article got a lot right but then charging for community membership is a super bad idea.

The open source community defies definition. It's a diverse multitude of people with different motivations. This will ensure its survival even under challenging circumstances.

There is a risk, maybe significant, of the generational hand off. A lot of folks who built this rich legacy were academics and pioneers motivated by ideology. Software has moved on from early pioneers motivated by liberty and freedom issues to being subsumed by establishment interests.

At the moment there is also widespread cynicism about ideology in general and a lot of open source is increasingly developed by corporate interests. This could have repercussions for the 'nature' of open source as institutions and a connection to individuals beyond their identity as 'users' has not really been built.

Here are a few ideas off the top of my head for a purely open source (non-commercial) project:

* custom features

* prioritization

* training

* enterprise support

* sponsorships

* invites to free conferences and swag

* t-shirts and swag sales

* commercial software integrations/partnerships

* brand sponsorship/inclusion on docs/websites/etc.

* professionally managed and scalable hosting

What did I miss?

err ICO?

I disagree.

By using a small project and reporting bugs you are helping to test it, giving feedback and allowing it to grow.

Also, reporting a bug sometimes saves the maintainers the effort of finding the bug themselves... something that actually takes time.

A better policy is to encourage people to help fix the bugs they report, with a test case or a pull request if possible... something actionable.

maybe some sortof point system would be nice. You get points by providing good bug reports, good forum answers, good PRs, good code reviews, providing tests, donating, etc., but you can lose points by wasting people's time or being a jerk, for instance. Then maintainers can prioritize PRs by people with good points, regardless of how they got the points (be it from donating time, code, or other ways of helping the community & project).

The problem I see with that is that people gain and lose interest in a project over time.

Some other people become disenchanted with how the project is going and try to fork it when it doesn't go their way. This is not inherently bad... many good projects come from forks... but it is not an ideal situation to have.

The dude's key project has a total of 4 contributors (working at the same company?) 0 forks and 0 stars. I am sure we should all follow his guidance on the subject.

> annual fee for community membership

Sleepycat did this https://wikipedia.org/wiki/Sleepycat_Software and seemed to work out for them.

But if opensource truly is infrastructure, why not nationalize it? i.e. government pays maintainers a subsistence wage (provided they meet some scale crtieria, perhaps similar to automatic royalties for pop-song airplay).

Users (i.e. big corporations) would pay a levy to fund this. Of course, it could be set up privately, independent of a government.

Well some OSS is developed by universities and research institutes, which is a form of indirect nationalization.

That would make it unfair for indie developers... Then they'd be competing with institutions. This would actually kill open source as we know it.

You misunderstood -- the parent said this is already the case. A lot of FOSS is already heavily subsidized, from grants and tax money. No "would"s needed.

And yes, it definitely makes it harder for indie developers to "compete", because these institutions run on infinite slave labour (students and postdocs). The only way to compete is on quality, which brings us back to the original "who pays for quality time" premise.

Because who decides what projects deserve how much? Who decides that a project is even worthy to receive anything at all? If there was such a government program, what would prevent masses of inexperienced developers to start pointless projects, open source them, and file a claim to receive money from the government?

> perhaps similar to automatic royalties for pop-song airplay

From http://www.nolo.com/legal-encyclopedia/copyright-compulsory-...

In order to take advantage of this compulsory license, a notice must be sent to the copyright owner along with a fee set by the U.S. Copyright Office, known as the statutory fee or statutory rate. The fee for recordings is currently (as of 2017) 9.1 cents per song (or 1.75 cents per minute of playing time). To verify the current rate, check the Copyright Office's guide to compulsory licenses. On the site, you can click “Mechanical Royalty Rate.”

Maybe we can try finding useful metrics then. And of course they could be gamed but then we can adapt and improve. By example start with number of stars on github or number of forks or even views (with verified users). Actually, we have such kind of measure, it's called advertising. It's one of the few working business models on the net but it works with a kind of bizarre tax on physical goods. Why not with a levy ? Edit: typos

Infosocialism is my favorite kind of socialism, because of how artificial intellectual property rights are in the first place. Since content is so easy to copy and benefit from, why not pay for it globally rather then trying to pay for it with artifical bounderies to create a fake market of monopolies? Of course, there are lots of problems in the idea, but the ideal is solid in all its forms.

What works for me is locking down the application behind a plan. Users can submit whatever feedback, bugs, suggestions, enhancements, and wishlists they want. These contributions are important, but they won't change the roadmap.

This only works when an open source application becomes ubiquitous or nearly ubiquitous and the users want it everywhere. Popularity and consumption rates are irrelevant to whether this works. This is because ubiquitous software solves an extremely common problem and takes too much effort to replace with an alternate solution. Ubiquitous software is not necessarily good software.

When somebody wants a change in the roadmap they can pay you money to compensate you for the additional time it takes to pivot into another direction. You probably aren't going to make any money like this. Then benefits of this approach is that the maintainers won't burn out. They just work to the plan and occasionally respond to issues. The software has a transparent and published trajectory.

That's the right approach. The question is whether you can keep enforcing that - sticking to the product roadmap and release plan - if/when a large software company becomes a "customer" of your open source project. That's when it requires a tremendous amount of discipline to stick to this. But the right approach.

> When I say “open source”, I mean code licensed in a way that it can be used to build proprietary things.

This redefinition of a basic term should have been at the beginning, not the end.

And so should "open-source code is utility software".

Stallman was right when he said that the Open Source movement would eventually abandon any conceptions of software freedom - it seems to me that we now have a whole generation of "open source" contributors for whom the only type of freedom that matters is the freedom of downstream developers, rather than users, and who seem to think that the role of open source in the world is just to provide a base on top of which one can write proprietary applications. Where do developers of open source end-user applications fit into this picture?

This year's LinuxCon has been rebranded under the umbrella "Open Source Summit".

Maybe it's time to fork the term "open source", as was done to "free software".

I maintain both types of open source projects. I, for one, am happy that we are trending towards more so-called "developer freedom" in open source. I never actually abandoned the concept of "software freedom" as defined by Stallman because I never bought into it in the first place.

Thanks...this is the best attitude I've heard. Instead of making people feel they need to take sides in the open-source vs free-software debate, better to just acknowledge that both are important and aren't necessarily in conflict.

They're not in conflict, per se, and they are indeed both important - but progress towards one of these goals has the advantage of serving the goals of megacorps, while the other one does not.

FWIW, I work as an open source developer on a strategic "infrastructure" project that my employer funds because having an open source base platform serves their commercial interests - and I'm very much okay with this, it absolutely is a good thing for them to be contributing to, but at the end of the day we're also a proprietary software firm. I'd just like to see more work go towards figuring out how to fund developers whose projects aren't of strategic interest to proprietary software companies than articles that keep making the assumption that all important open source software is libraries or utility software that ultimately would line up nicely with corporate interests.

> I'd just like to see more work go towards figuring out how to fund developers whose projects aren't of strategic interest to proprietary software companies than articles that keep making the assumption that all important open source software is libraries or utility software that ultimately would line up nicely with corporate interests.

To be clear, I do agree with that goal. I just tend to diverge with others on the means. That is, I don't agree with hacking the IP system to achieve that end. I'd rather see the IP system done away with entirely. (IP and software is near and dear to my heart, but IP itself is so much bigger than just software.)

You make a good point.

Still, as enthusiastic as I am about the purity of Stallman's pure goals, let's not have the perfect be the enemy of the good. Freedom for developers isn't hurting anyone – if anything, it has resulted in so much software that, while free, also doesn't need to be astronomically expensive. Imagine how much you would have to charge for a web app if you had to rely on non-free software only. What would a stack like that even look like? Windows, IE, ASP, IIS, Oracle, a paid UI library (or equivalent dev hours) ... the tools itself would be expensive enough to make most of the software market disappear.

I'm self-employed, and I know my job wouldn't exist without free dev tools.

The author has many good points however it's either his writing style (thinking), ideas, or conceptual mental model where he is missing the point of open source. It is actually a bit confusing. His title doesn't correlate with what he writes later which contains several somewhat vacuous statements. People love to work together and produce something for the common good, humanity wouldn't be here without that good feeling and collaborative spirit. open source comes from people's time, time has led us to a point where open source is everywhere. Not all people are greedy, every coder owes another coder their livelihood. I think this draft just needed like 100 more edits. Also, "Many" does not equal 3.

In the proposed approach, what would happen to a high-quality and desirable code contribution from someone who cannot afford to pay for their code to be reviewed?

I always wonder where coders find the time to significantly contribute to Opensouce projects - which many seem to do - after their day job, having played and eaten with their kids, and were an attentful husband.

A lot of companies encourage open source contributions and maintenance. Some companies even have departments of engineering dedicated to open source. And yes, when people like the community and technology, contributing does not feel like work. Some contribute because of more “practical” reasons—still, completely legitimate—such as improving their visibility for job hiring. It is always impressive to get a résumé with a GitHub and StackOverflow links.

My company's platform is built on open source tech, a lot of which isn't mature yet, so we end up fixing bugs and adding features to it at our day job. Upstreaming them to the community is another story, and even when the code is finished and tested, things like backwards compatibility on old versions of the package and running on platforms you don't use can be a bear to support. It's definitely time consuming even when you can do the development at work.

My experience on other open source projects has also been when you put the work in to open a relevant PR and the maintainers just never respond to it. That's definitely frustrating.

I have a solid 1 hour train trip to and from work. Because of where I live I get a single train and always have a seat. Thats where I get the majority of it done.

I did a lot during University years (while in a different major). I learned, I taught people, it was really fun. Now I only have the time/energy for 2-3 simultaneous side projects, with only 1 being open source at the moment. There's no way I could be doing the same was I married and with kids.

I did a lot after school ages 19-23. Now after work I want to play games, spend time with my girlfriend, watch movies, and read books. And if I want to code, it's to learn an interesting technology (sometimes I mix this with contributing). It seems that unless programming is your main hobby, it's hard to find the time to do it.

Or wife...

You might want to stick a debugger on your assumptions about who does and does not have children and/or a spouse.

And/or a day job.

Programming is my hobby as well as my job. I don't think it's controversial to say that people can find plenty of time for their hobbies, even with a family; therefore, you would expect someone to have plenty of time for programming-as-a-hobby.

Yep, that agrees with one rule I've found very helpful in my Sidekiq project:

All free/OSS work/discussion is done in public.

Never private email, never Slack. Always open an issue. Security issues are the exception here. No one should get to monopolize my time without paying.

I like the idea of donating to projects that benefit me, so the developers working on those projects have a financial incentive to continue doing so. For example, I'm interested in the Crystal language, so I give the project $10 a month. Yeah, it isn't much, but if enough people did this, it would allow open-source developers to make a living out of these projects, rather than being enslaved by them to the point they burn out.

Something like Gratipay is good for facilitating that use case but I don't know that there are enough other devs out there willing to fund these projects themselves. At least I haven't seen one yet where the maintainer pulls in anything like a normal developer salary for their experience level.

I don't get the jump the author makes from "your time is valuable" (understandable) to "you should have to pay to contribute to open-source projects" (umm, what).

I run a relatively popular open source project. I think that there are some strange forces in the tech industry which make it nearly impossible to get big companies to use your project.

Maybe it's not right but I really feel like not being based in Silicon Valley has something to do with it... Related to branding, social networks, bloggers. Outside of SV, it's very tough.

Only small startups were using my project initially; literally hundreds or maybe even thousands of small startups but not one large corporation (that I knew about).

It's been 4 years though and the good thing is that now several of the startups that were using my project got really big and are growing fast. Still no big corporations but it doesn't matter anymore. Me and one other contributor are now able to make money offering consulting to those startups which grew. Also we have a sponsorship deal now.

Maybe write your article after you've done this and tell us how it worked.

I just stumbled on a note from the abandoned project [History.js](https://github.com/browserstate/history.js/):

> Despite History.js being one of the most popular JavaScript libraries there is, and has been used by even multi-million-user companies in its time - the reality of economy and company practices seems to be that companies prefer to fork their own internal versions and fix locally with their own devs rather than fund open-source maintainers what they would pay their own devs to make things better for everyone, including themselves, which would be cheaper - but no, that would require too many tiers of company approval that don't understand the need.

> As such, if you are an open-source developer, I'd recommend just working on open-source projects that are paid for by your own consulting work or your own company (e.g. every successful open-source project). As otherwise, when they become popular, you better hope they are easily maintainable and testable, otherwise the cost of maintenance is higher than the free time of the maintainers.

>> Don't give away your time.

>> But do give away your time and money to work on my projects.

Come on.

I've considered opensourcing some business products and researched the various models for doing so. I found three main ones:

* pay for support, like ardour

* pay for additional features, like gitlab on-premise

* pay for hosting, like piwik, or gitlab.com

I'm not a big fan of paying for support, like mentioned in the article, because support is not just something you give to your users, it's also useful for you: if someone spotted a big bug (possibly a security issue) but is not paying for support, don't you want to know it? Asking to pay for support is also creating a lot of tension, because people will ask for help anyway, and you have to tell them they won't receive it if they don't pay.

Paying for features is an obvious and efficient way. But I also like the idea that someone in a country where what I consider a decent price is actually a big part of the income can still manage to use my product to its full extent, provided they make an effort to use it.

That's why pay for hosting seems the best way to me for opensource products : everybody can use the product to the full extent, no issue is ignored, people pay for comfort.

Obviously, this works for the products I mentioned because they are ... products, and not libs. But I think it can apply to libs as well:

* pay for support : the idea mentioned in the article

* pay for features : this is something Sidekiq is doing, would love to know how it goes for them

* pay for hosting : this one is tricky, maybe offer to help implementing the lib in customer product? Hardly scalable, though

I would say that for libraries, paying for additional features is what makes the most of sense for me.

I think a crowdfunding site specifically designed for software projects would go a long way toward solving this problem. Something like this: http://www.daemonology.net/blog/2017-05-11-plan-for-foss-mai...

About any software stack for about any computer task involves at least some open source code running for you, written by someone on their free time, mostly out of pure altruism. I wonder how many dollars has this person contributed to, say OpenSSL, or to GnuPG, or to the GNU project, or to Linux, or to the Apache Foundation, &c.

If you dont want to respond to pull requests or to emails, just ignore them or dont put your code up on a platform that allows these. Publish release tarballs. Nobody's obliged to accept patches. But what this article tells is a merely a shortcut to making someone hard-fork your project. If I have to pay to get my patch upstream, well, I'll just maintain my patchset against upstream instead, if there are no alternative projects.

Why does the text on this website have 52% transparency?

You gotta pay to get 100% opaque.

It's actually 52% opaque, so 48% transparent. But yeah, that's crappy as heck.

I just assumed they'd chosen an annoyingly faint shade of grey. For some reason, the transparency seems even more perverse. I had to zoom quite severely to be able to read it.

Glad to see other ideas and operating models being proposed and tried.

Most of us live in countries where you need money to pay rent and buy food. Unless you're already wealthy, that means you need to work (trade time for money) or find a way to trade time for an ownership stake that will, you hope, generate income (and in the process that stake becomes itself more valuable).

A buddy of mine in a maintainer for a popular Drupal module. A very large, well known, social media platform uses it. One day he got an email from someone - likely someone making $150-$200k- more or less demanding that he review and accept some PRs, as well as do some work himself, for a feature they needed.

I told this friend "Ok, did you ask them about their budget to pay you for that?" My friend, more idealistic than me, looked at me like I had 3 heads at first. But he got my question. Nonetheless he decided to "honor" their request and proceeded to work several weeks unexpectedly - for free - so the large for-profit company could stick with its plan and the person requesting this, who is paid, could meet her/his commitment to their boss. His rationale was afraid he'd criticized by the community for not dropping his paid work (!) to do this, since he was the maintainer. He did not want to be a "sell out". I think his decision was insane but such is the pressure to stay true to the ideals.

These stories are all to common and similar to what Willian describes.

I do work around expanding computer science in schools. I do work around mobilizing tech communities to lend their tech skills to disaster relief. A lot of folks in the "startup tech" and open sources communities (different communities with overlap) do the same -- I'm seeing them show up in big numbers for Irma volunteering right now for example. I view these efforts as akin to open course - they are contributions people make of their (unpaid) time to the greater good.

The big tech companies by contrast, many who got their start using open source software and many of whom still power much of their systems with it, could do much much much more on any number of fronts - CS in schools, supporting civic hacking, etc - than they do now. I am sure folks within those companies think they do a lot, but it's not, in my opinion, 5% of what they could do.

And when they do get involved in causes they make huge, often unreasonable expectations of unpaid volunteers in order to minimize their donation, whether that's a donation in time or money. (Case in point: last year a large tech company that provides search and email services asked me to organize Hour of Code events at 30-40 schools around NYC at which their staff to volunteer for an hour or two -- planning and logistics work that would have taken me 1-2 days a week for 4-6 weeks at least. They balked at the idea of paying me for my time since this was a "cause" and I should do it for free, though of course the people who would have been working on this project with me from said company would have been paid.) Sound similar? Expect a ton from volunteers to minimize your own investment.

I bring this up because the LEAST that people who work on open source projects - at least those who aren't pulling in $300K at one of the big tech companies - and ESPECIALLY maintainers, should expect is to get paid somehow. Seriously, how are people supposed to pay rent? William is right on with his piece.

Ideals are great but people need to eat. This emerging duopoly in tech where on one side there is a group of people who are entitled to make massive wealth and demand huge salaries and, on the other, are the open source maintainers, civic hackers, and computer science teachers who are being disloyal to the noble ideals of tech for not wanting to eat cat food is serves the industry poorly.

I engage in this hyperbole to make a point -- an industry that was built by many idealists who saw tech as being an engine to democratization and equality is now becoming exaggerated mirror of society large.

And if you're one of those making $250k, $300k, $500k at some tech company and demanding people work for free or else you'll accuse them of being sellouts for wanting to pay their rent -- well, look in the mirror before you cast that stone.

Reviewing and either accepting or rejecting (in full, no need to cherry-pick) large PR's is entirely up to the author.

You were right; the safest way is to simply ask if they're willing to sponsor that custom work, and how would they like to be credited for their sponsorship.

There's no need to go crazy about it. If it's not a right fit for the project or too much effort for the maintainer, then they can pay or it will just go undone. No one has to sell out in order to simply ask for someone to sponsor a feature.. it's simply logical to just ask for a contract or donation, or reject the PR if it's too big.

Yes. That sounds reasonable.

The problem comes that, as with many things, people like to live others' values for them. People become unreasonable. My friend was worried that he'd lose the respect, unreasonably in my view, of the community for not doing the "right thing", which in his view was dealing with a feature and set of PRs that were not on the roadmap to happen just now. And that word "sell out" - his word - for asking to be paid for his time was the root fear.

Understood completely and agreed.. but (almost) everyone has to 'sell out' by taking a job. A bit of reticence in this area is noble but perhaps misplaced, and people who get at least somewhat comfortable in asking for other people's money (aka selling out) might tend to not have as many concerns about money or pull requests. ;)

It sounds like big companies are using "sell out" as a weapon to get free work. I don't think someone drawing a large salary at a large company asking for free work is allowed to call anyone a sellout.

"One day he got an email from someone - likely someone making $150-$200k- more or less demanding that he review and accept some PRs, as well as do some work himself, for a feature they needed."

This is called a 'business opportunity'.

Seriously, people are going to ask you for free stuff all the time.

Sometimes they'll be up front about it (as in, "we don't have budget for that, but can you still help us out?"), and sometimes they just won't specify initially if they are willing to pay or not (ie, they'll just make a demand).

Every interaction is a negotiation, even if you are led to believe otherwise.

Yes, and hence my suggestion to him.

But this is also why I introduced my only vaguely related example of the large search engine company who wanted me to work for free to help them organize 30-40 school events for Hour of Code -- a big undertaking. They just said no to my request and did not do the events, and implied I was the reason why those kids wouldn't benefit from their hour or two at each school. No "'business opportunity'".

As context I do A TON of free work already in schools around computer science education. Was I being unreasonable to ask to be paid for this work? They sure thought I was, even though the people in their CSR group who'd have been the PMs of my work sure as heck get paid. The company chose just not to do the events at all (w/ a market cap of both of $500b) - the kids lost out too.

It's actually not so that the request for free work is a negotiation technique - it's an actual expectation of more and more people in the tech community who will get angry when you won't work for free (and they'll convey that anger from the desk of their $250k/year job).

I at least am seeing this dynamic play out all over the tech world. Work in a big tech company, nominally as a software engineer but really as someone who makes a lot of PowerPoints and watches (and "likes") a lot of Ted Talks, and the ecosystem seems to be ok with you pulling down $250K (and from that comfortable seat demanding quicker response times from volunteers in the tech community of various sorts).

Work for yourself selling your time as a contractor in the "gig economy" and you've become the maintainer and/or a significant contributor to a couple OSS projects that are related to the services you sell: you're a "sell out" to the ideals of open sources for wanting to be paid for that time. Again, I exaggerate this duality, but it's starting to become a real problem, I think, for the industry.

> you're a "sell out" to the ideals of open sources for wanting to be paid for that time

Who the hell unironically uses the word "sellout" anymore? Especially in this context?

I really don't think this is, like, a common opinion or anything. I haven't ever encountered anyone criticizing people for getting paid to work on open source software. Many projects I like (RPCS3, mGBA, libretro/RetroArch, GhostBSD, Redox OS, Godot Engine, Matrix.org) are funded on Patreon. In large projects such as FreeBSD, many commits are sponsored by either various companies or the project's Foundation. And specifically contractors contributing to projects related to their services, as you mentioned? That's how a ton of javascript libraries are developed :D And everyone is mostly just thankful that these projects exist.

What the hell are those "ideals of open source" anyway?

If they sent patches they already did the work. They might have maintained the patch against mainstream, but they contributed back instead. Your friend was under no obligation to merge. I cant see any free labour here.

Your friend's been played for a tool, but I think you know this already. It happens all the time, especially with naive and insecure developers but not limited to them - our corporate overlords are always looking for some new way to encourage people to work more for the same amount of money. Hooking people on their ego is a very easy and common technique. Often people will just do it to themselves just fine with no help.

Personally, I either code for money or for a cause. The latter will almost always require some sort of GPL licence.

The social contract of open source is to give away code and time to open source to enhance the community and software. The problem that open source projects really have is that raising and or selling a product is a goal that not every person with a successful project has.

If you want to actually have people pay for open source you should look into making a grant style system for people in open source that is targeted to maintainers. Google Summer of Code and Aigrant are good examples of this.

The author seems to believe contributions of code or contributions of bug reports are a net negative for the project, while the only thing that the project needs to survive is money to pay for the author's time.

That is exactly backwards. Nearly all open source projects actually do not need any money at all to grow and prosper. They simply need contributions.. of time. In the form of bug reports and code.

Take care of your users, first, and the money will follow.

They do not need it, but it'd help quite a lot. If I got a bunch of money for doing open souce I could:

- Not find random jobs to be able to live, so more time for open source.

- Have more energy for open source (so important it has to be a separated point from the previous).

Cause vs effect. Money is the latter ;)

This is true for some. Though I'm not sure it always applies. OpenSSL developers needed money to guarantee their time, yet for years it was not much money.

I hope the OP doesn't seriously believe that charging for open source work will somehow "fix the diversity problem", rather than magnify it.

I'm hoping that was just an off-handed line that didn't get much thought before being added to the post.

"Do you want to get forks? Because this is how you get forks."

Maybe not lock non-paying users, but give paying users a bigger priority and the ability to promote non-paying user's requests if they're good.

IMHO, the fundamental problem of these burnout open source projects is that they are "marketed" (deliberately or otherwise) to non-decision makers and people who don't control the budgets in companies that need their software. I.e. The lowly developers of some complex hive of a deeply hierarchical group of code monkeys in a for-profit org that's typically not in technology.

Red Hat, Google, Microsoft and Oracle all know the value of open source because their big wigs are keenly aware of its value.

Alt currency is an option for open source project. I think GitCoin is on these lines

Would be nice if projects were organized with the Aragon project

>If you’re the leader of one of these projects, charge an annual fee for community membership. Open source, closed community. The message to users should be “do whatever you want with the code, but pay us for our time if you want to influence the project’s future.” Lock non-paying users out of the forum and issue tracker, and ignore their emails. People who don’t pay should feel like they are missing out on the party.

This could be the dumbest thing I have ever heard of it. I mean seriously, you want people to pay even for PRs they have already written?

>Also charge contributors for the time it takes to merge nontrivial pull requests. If a particular submission will not immediately benefit you, charge full price for your time. Be disciplined and remember YAGNI.

This sounds like a great way to lose all your real contributors. The article mentions "get paid for your time" over and over again, yet who is paying me for the time to write the code for the PR? You expect me to both dedicate my time to writing the code for a PR, and then pay you for the privilege.

Perhaps what projects worrying about work for commits should require rigorous testing (integration tests at the very least) on unknown PRs if they ever feel the need to do something like this. And limiting feature requests is understandable, but most projects already ignore overly specific feature requests. Charging for PRs though seems like the fastest way to have your project forked, and have you lose control of it, or for it to split the development talent and die completely.

Merging PRs isn't as simple as clicking a button. I wrote this months ago in another comment: https://news.ycombinator.com/item?id=13231590

> most people are only willing to contribute to open source to the extent that it scratches their itch. They feel that their obligation ends as soon as the code is written, and the maintenance of their code falls on you.

> So from a maintainer perspective, you have to act like people's contributions are your contributions. You have to evaluate the code as if you have to maintain it later, you have to understand the circumstances surrounding it, etc. You have to be aware of everyone's concerns at the same time and make sure you don't end up messing up other people's use cases without good reason. And more often than not PRs reflect a "selfishness" of sorts wherein it solves their problem but breaks the general case.

I understand both your perspective and the perspective of the maintainers who do it for free. Spending all your time dealing with pull requests, code review thereof, etc is a huge hastle. On the other hand, no one is going to do free work, then pay to have it merged.

I would offer a compromise. Freely accept requested modifications. Project maintainer creates a list of features he/she will willingly merge. Any other contribution would be a pull fee.

Either way, I'm amazed that people working tirelessly for free to promote open source all these years hasn't hit this problem yet (burnout due to lack of proper monetary compensation).

I wish all maintainers luck.

> You expect me to both dedicate my time to writing the code for a PR, and then pay you for the privilege.

No, better yet it would eliminate PRs from entitled users who think this way — who believe they contribute value by writing up issues and submitting minor pull requests that address their own needs, while remaining blind to the far greater value they receive from the project’s much larger code base; the mammoth time investment of the people who have designed, developed, and maintained that code base; and the thankless job those leaders have done nurturing a community often comprised of far more takers than givers.

Basically, the proposal eliminates the takers. Whether it would work or not is an open question. But if you find yourself feeling indignant at the very suggestion, then maybe take a hard look at which role you really fall in?

Eliminates the takers? The maintainer could just reject the PR to "eliminate takers" rather than setup a more complicated system of payments and different classes of users, some of whom pay to have a voice, and some who don't or can't.

> This sounds like a great way to lose all your real contributors. The article mentions "get paid for your time" over and over again, yet who is paying me for the time to write the code for the PR? You expect me to both dedicate my time to writing the code for a PR, and then pay you for the privilege.

It certainly sounds absurd on the face of it.

On the other hand, I can think of at least three cases where I'd do the work of submitting a PR if the project in question required me to pay.

In each case I can't currently gauge accurately enough whether these projects have a well-functioning development process. I could easily end up with a bitrotting PR with the project lead making a not unreasonable argument about why it's rotting (their time is limited, something else is taking priority, etc.). I imagine I'm not the only person who's ever been in such a "holding pattern."

On the other hand, if a reputable project says they'll take money in order to merge a branch I want, things become less amorphous very quickly. A project lead is not going to get away with blowing off a bitrotting merge request, at least not without their project's reputation (and future income from PR's) taking a hit.

edit: clarification

Reading this makes me wonder, though... These maintainers are often well-paid professionals. If their lifes outside of their day jobs put the pressure to limit the open source work, what is a little money going to do? If money was their main motivator to compromise their personal life, would they not already have gotten a second job (like a part-time consulting gig), maybe instead of the whole open source thing? Makes me feel as if this article misunderstands the motivations of maintainers.

Not every developer is a highly paid superstar in Silicon Valley. When needing to juggle family / life, I'm sure this proposed model would make it a lot easier to explain to the wife/husband/partner why they need to stay up a bit longer at night to work on their (previously) non-paying projects.

You need to show income to justify your hobby?

As a potential contributor I need to know whether there's a professional process or a guy "playing with trains" on the other end of the wire.

The problem is that the FLOSS ecosystem doesn't give you an easy way to tell. So if I misjudge and hit a wall of dysfunction, the general response would be, "Well, the maintainer just wants to play with trains. Leave them alone and fork the project if you want it to be some other way."

At least with paying to contribute, it would force the FLOSS ecosystem general response to be, "Those maintainers are just playing with trains, but they're taking money as if they are professional engineers. That's bad." Of course that's worst case scenario-- best case is that they really are engineers and I'm funding their development. Either way, it's potentially better than the status quo which is that you have no idea until you submit the patch.

I'm not saying that's what they are, but somehow I got the impression that maintainers of projects that are good enough to attract payments for pulls, would have marketable skills, and be ahead, regardless of the market they live in.

My thoughts exactly. What a steaming pile of crap...no wonder that the OP has zero public repositories which have contributors...in fact all of the OP's repositories are forks.

Regarding PR and paying, people fork the code and make the changes they need. They send PRs to avoid merge conflicts in the future. i.e it is in your best interest to get your code merged.

You are not obligated to send PRs. You can fork and let it sit there.

Regarding community management, past a certain scale you should charge for it. People often feel entitled and will waste your time instead of reading doc. Majority of OSS projects rely on a handlful of individuals; often 1 or 2 people handling everything.

I completely understand the spirit of this.

OSS is not charity or altruism. Share your code out of self interest (e.g contributions, forks, bug detection etc.) If you get nothing out of it, unsubscribe from notifications.

You don't owe people your time, skills, energy.

I've never really worked at a place where we had any spare time for open source project development, nor time to opine on the social issues of the day. Must be nice, but I feel like a very small, privileged few actually live in that world.

The rest of us have work to do.

Nor have I. As a manager/co-owner I can't think of a reasonable business-friendly way to allow my developers to spend work time on OSS. I would love to, of course, but our systems really do not facilitate community involvement.

The majority of my contributions have been around projects I use for work. Bug fixes, extending functionality, performance enhancements, etc.

That's the real answer.

If you spent 1/10 of an engineer on an open source product, and 100 other companies do the same, your company gets much more than it puts in. And because it's open source, you know how to fix it, and you can fix it.

I know of multiple billion-dollar companies who can't get the time of day from Cisco, HP, etc. for bug fixes or new features.

The vendors attitude is: Bought 10M of product in the past year? Meh... piss off. We're working on important customers.

> I would love to, of course

If you did, you'd have found a way for it to work.

Making a pretty cool deploy script? Document it and put it out there as OSS.

Making a class/module to sort items semantically? Make it OSS.

Someone made an IDE extension to syntax highlight WebVTT files? Make i OSS.

Made a file lister/selector for JQuery? OSS.

Integrating 3rd party X with 3rd party Y? Opensource your module for it.

Unless all your developers do is hack stuff badly together in a monolithic mess, some of it can be opensourced.

I read parent comment as referring to contributing to an existing active open source project vs just making things you've built open source.

It's one thing to write the code, but another thing to publish as open source. There's overhead: coordinating the PR in an existing project, responding to issues, writing a decent README, looking at PRs, etc in your own.

Your company almost certainly makes use of multiple pieces of open source software. What do you do when you need a feature that doesn't yet exist in one of them?

This smells like a small-minded startup-bubble nonsense to me. If you have time to use open source software, you should make time to also submit fixes and open some of your work.

That’s not to say startups don’t contribute, but my experience is that a lot of startups—usually led by inexperienced managers—see contribution as giving something for free instead of charging. Small-minded nonsense indeed.

Lots of companies use open source code but don't actually require any changes to be made. A lot of industry standard open source software requires no code modification of the source for the vast majority of applications. Examples being Nginx, Python, Apache Web Server, Tomcat, pretty much any enterprise level application. So many people use it that for the 99%, the code already exists, with 99% of the use cases being heavily tested.

Now they could be donating some amount of money, but that's in no way required.

All good. But then, the same people could contribute code non-pertinent to their product as open source. As someone else said in a comment here, you can always find what to open source. There is really no excuse.

> This smells like a small-minded startup-bubble nonsense to me

Small-minded, no doubt (though "business"-minded rather than specifically startup).

In my national context (Australia), the vast majority of companies, small and large, operate purely in the fundamentalist capitalist mindset. There is no 'should' (conceived ethically) in their stock of concepts. It literally doesn't exist (where it occurs it's just a PR exercise, which the PR department will translate into management's native dog-eat-dog language for their comprehension in meetings).

Ideally we wouldn't work for such companies. But the stock of jobs at better places is limited, so by statistical definition 'most' of us won't be there.

A lot of open source work gets done outside of regular jobs. And it also contributes to burn outs. In order to maintain my projects I am spending a subtstantial amount of my free time and it takes its toll.

I'm not sure why the downvotes, other than you express an unpopular opinion.

My experience has been two extremes:

1) companies that use open source, modify it (to the extent that it's largely proprietary), and deride the open source community that competes with them

2) companies that use open source to leverage non-core functionality they need... and move on with their real value-add

Companies in the style of (1) never contribute back. They see open source as the competition, even though they use it themselves. They don't understand that proprietary extensions are just that... proprietary software in a non-expertise area, that no one else in the world knows anything about. Instead, they spend more and more money "fixing" things which were already fixed in the upstream releases years ago.

Companies in the style of (2) contribute back minor bug fixes or features which are pain points for them. They sometimes pay for other people to write new features.

I say this as someone with 20 years experience working on both sides (corporate / open source) for companies doing both (1) and (2) above.

I think both of your "extremes" are flawed, but for a lack of time I'll just add the big one you missed entirely:

0) Companies funding the full development of large OSS projects. Examples: MySQL, Postgres, nginx, Chrome, Tensorflow, React, (Most of) Linux, Redis etc. etc.

You do realize I said my experience, right? Not "these two examples encompass all possible corporations".

This is something I've been thinking about for a while as well. All these companies with regularly updated blogs, super active social media feeds, employees sent to present/attend every week or so and open source project development being done in house...

Do they ever do any actual work? Because every company I've seen or worked for has wondered just how they have the free time to do all this stuff with bill paying client work to attend to or a product/service to maintain.

Or do they simply have a one hour work week like a fictional character would?

http://tvtropes.org/pmwiki/pmwiki.php/Main/OneHourWorkWeek

It's just marketing. Rather than spend $$$ running ads they spend a few hours of their workers' time updating blogs and social media. Open source serves the same purpose, plus you might get some external contributions. And it might create a social environment that pushes your employees to work on their free time.

Reply on news.ycombinator.com