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.
How is that an issue in this day and age? 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.
Examples of PRs that "work" exactly as intended yet are the wrong way to solve the problem:
Here's a large PR:
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:
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.
If you want commit access, just ask. But I still want to validate releases that get pushed out to a bunch of people.
I use this feature at work so I can confirm it behaves as expected.
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.
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.
> 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.
This applies to engineering at software companies as well.
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.
Burnout can happen by working too much. It can also happen by too many discussions/politics if you give out commit rights like cookies.
> 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.
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.
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). Sounds like a joke, but it's a way to show what are you up for.
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.
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.
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.
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).
The alternative brought to it's logical conclusion is Shkreli and rasing medicine prices by thousand percent.
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."
> 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.
edit: This down-voted too? The clarification?
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.
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.
If this were strictly enforced, there would be much fewer open source projects, as not all authors would be able to meet the obligations.
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.
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.
> 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.
Ehm, your quote does not quite support your statement:
>We do not generally prohibit use of GitHub for advertising
It's like building a business on Google Reader or FB Parse.
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...
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.
However, the donation is about helping poor children in Uganda, not about running the project.
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 too would gladly pay one dollar for a hundred dollars bill.
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.
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.
Basically, "BSD, unless you're a $1B+ valued company that is not paying our software foundation $10k/mo".
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.
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.
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.
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.
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)
"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."
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.
I'm not sure how successful it is, but Crystal seems to have the right idea.
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.
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.
As a home tinkerer I do agree with you. And glad Haskell and Linux are available for free.
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.
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.
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.
If you're employed, why would you care? You're getting paid the same, the extra time is your employer's problem.
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.
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.
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.
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.
* custom features
* enterprise support
* 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?
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.
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.
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.
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.”
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.
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.
This redefinition of a basic term should have been at the beginning, not the end.
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?
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.
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.)
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.
Maybe it's time to fork the term "open source", as was done to "free software".
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.
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.
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.
> 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.
>> But do give away your time and money to work on my projects.
* 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.
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.
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.
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.
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.
Who the hell unironically uses the word "sellout" anymore? Especially in this context?
What the hell are those "ideals of open source" anyway?
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.
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.
Personally, I either code for money or for a cause. The latter will almost always require some sort of GPL licence.
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.
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.
- 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).
I'm hoping that was just an off-handed line that didn't get much thought before being added to the post.
Red Hat, Google, Microsoft and Oracle all know the value of open source because their big wigs are keenly aware of its value.
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.
> 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.
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.
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.
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?
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 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.
The rest of us have work to do.
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.
0) Companies funding the full development of large OSS projects. Examples: MySQL, Postgres, nginx, Chrome, Tensorflow, React, (Most of) Linux, Redis etc. etc.
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.
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.
Now they could be donating some amount of money, but that's in no way required.
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?
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.
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.