1. 38
  1. 22

    The greatest trick the Devil ever pulled was convincing us the BSD license means “free as in beer”, not “free as in puppy”. All software rots.

    1. 8

      I love the phrase “free as in puppy”.

      1. 6

        “Free as in mattress” is the bleaker version.

        1. 6

          Mattresses are a lot less work than puppies.

          I’ve been using “free as in mattress” for projects that I make freely available but am not interested in accepting contributions for or supporting beyond simple, obvious bugfixes. You can have it, but I probably don’t want to hear about how it’s going.

          1. 5

            Pretty sure it isn’t the mattress itself that is the expensive part…

    2. 15

      Maintainers are already busy people, so you also don’t want them to spend half their time writing grant proposals detailing what they plan to do so you will fund them. Instead, fund them so that they can dedicate resources to the project, and trust them to direct those resources like you’d trust a senior engineer to execute on a broadly scoped project.

      My wife is in science, and look in from the outside, it does seem like a huge amount of time goes into writing the grants vs actual execution. Maybe it’s because execution is grind and not a sprint to the deadline, so it doesn’t come up as much at dinner time, but it seems like there is always a grant application that is due next week and everything else is on hold until that gets done. And she’s still on the low end. For people more senior than her it’s normal to hire people just to work on the grants and spend a year just polishing the application. It’s pretty bizarre if you think about it. Ideally you would want some minimal oversight after the fact to make sure the money wasn’t wasted, but there doesn’t seem to be much value added from all the prospective work.

      1. 1

        I think your impression is sadly pretty accurate. By and large, grad students and post-docs do science, and PIs write grants.

        1. 1

          It depends a bit on the funding body. DARPA requires a lot of paperwork but then provides a pretty large firehose of money to people that keep producing good results. EPSRC grants are usually small but they also have programme grants that are big enough to fund a team spread across a few institutions for several years.

          1. 1

            That’s fair. Another exception I know of is Howard Hughes Investigators. I painted with too broad of brush. The exceptions certainly exist, but they are a small minority of researchers.

          2. 1

            That is standard business practice in the EU as far as I know: hire people to write convincing bullshit to get grants/subsidies.

            It’s only sad if you’re not enjoying capitalism. /s

        2. 12

          Nice article, hopefully it catches on.

          I often read advice along the lines of “if you want to help a project send PRs” and I never understood it. Reviewing and iterating or pushing back on PRs is work! Often more than writing the code itself.

          Yes, but it is a lead-in to gain other maintainers. Other people are also subject matter experts in different fields or have priorities that the maintainer doesn’t. I don’t ever expect to bother to learn how window and input setup works on MacOS, but if someone does contributes something I’ll take it, and if someone else fixes bugs rather than asking me to figure out how to fix them, I’ll take it. If your intent is to maintain the project forever more or less as it is, then vetting PR’s isn’t necessarily worth a lot of time and energy, but if you want the project to grow, then getting people involved and having them get used to contributing is a vital force multiplier. Very few people are going to drop in and make a giant and complicated feature addition or bug fix all at once; they often (but not always) get started with little doc fixes, refactors, cleanups, bugfixes, etc and then expand their ambitions once they’re comfortable.

          Being a maintainer is as much about the human factor as the code. Humans make the code, humans use the code, humans decide what the code should be.

          Instead, fund them so that they can dedicate resources to the project, and trust them to direct those resources like you’d trust a senior engineer to execute on a broadly scoped project.

          Totally correct, but difficult. In my (limited) experiences, people who can make decisions about those kinds of resources didn’t get to where they are by not being control freaks. ;-)

          There was something else I had a reply to, but I can’t find it.

          1. 8

            Designing, building, managing, and growing an Open Source project demonstrates all the skills required of a Senior Software Engineer. That means maintainers can access $150k–300k++/year compensation packages.

            Just between us, that’s 3x-6x going rate east of Germany. Even more east of Poland.

            A lot of open source apparently happens because in the US there is enough capital for people to take very long sabbaticals and/or for companies to take in couple more people than strictly necessary. I am very happy for it, because that means people around me in Czechia here can produce high quality solutions for the local needs even on measly $40k.

            On the other hand, most of local talent gets vacuumed up by transnationals who pay $50k or even $60k and then used to very inefficiently deliver services to the US market, slaving on legacy systems with zero passion, just to pay for their very expensive mortgage.

            If you really want to make sure that open source you so desperately depend on survives, you can potentially sponsor 3-6x the amount of well-qualified maintainers in the central/eastern Europe for the same price.

            1. 7

              people around me in Czechia here can produce high quality solutions for the local needs even on measly $40k.

              Yes, life in Czechia is also cheaper than in most US cities, and there are well educated engineers everywhere. :)

              If you really want to make sure that open source you so desperately depend on survives, you can potentially sponsor 3-6x the amount of well-qualified maintainers in the central/eastern Europe for the same price.

              The idea isn’t to overtake projects with cheap labor, but to fund people who created something in the first place.

              1. 3

                The idea isn’t to overtake projects with cheap labor

                Which feeds back to the issue. US / western EU engineers will produce some more open source much more expensively while engineers elsewhere will waste their talents cheaply taking care of legacy DHL or Accenture clients’ software stacks.

                Also:

                who created something in the first place

                There is no need to fund anyone after they did something, is there? For that you could have some sort of award system. Allocate some funds for projects that especially helped you in a given year and then let your developers vote on distribution.

                1. 4

                  Software is never done, it needs regular maintenance, hence the funding suggestion.

                  1. 2

                    Which feeds back to the issue. US / western EU engineers will produce some more open source much more expensively while engineers elsewhere will waste their talents cheaply taking care of legacy DHL or Accenture clients’ software stacks.

                    Well. Cheap labor isn’t about software or open-source. Open-source software developers are just realizing that they’ve been working for free, and looking for a way out. If you tell them “there’s no way out, we’ll just replace you with cheaper coders from $somewhere”, I’m not sure they’ll like your solution.

                    Do you think that it all comes down to “throw money at the project and find the cheapest way to get the work done”? That’s how we get maquiladoras where I live (and elsewhere).

                    There is no need to fund anyone after they did something, is there? For that you could have some sort of award system. Allocate some funds for projects that especially helped you in a given year and then let your developers vote on distribution.

                    Sarcasm. :)

                    Yes, that could work. Managing funds require a legal entity in most parts of the world though, and raises a lot of challenges based on organizing people, making them agree on stuff, paying them, taxes, legal obligations (like health insurance), etc. That’s also why “funds” are easier to share in the context you already know.

                2. 2

                  Yeah, I find the pay suggestion interesting because of how widely varying pay is around the world. The author also says:

                  you should target figures between 25% and 100% of a SWE compensation package

                  $150k/yr is 100% of a senior SWE where I live in the US (Ohio), which makes the high end of his range 200%. For this Google developer author, $150k/yr is probably 15-25% of a senior SWE.

                  There are just as competent engineers in areas outside of California, and I’m sure the engineers here in Ohio or where you live in Czechia are just as good.

                  1. 2

                    Just between us, that’s 3x-6x going rate east of Germany. Even more east of Poland.

                    Compare phk’s funding drive. More than 15 years old by now, but he wanted a little less than $60k - and he’s a uniquely skilled software engineer by most people’s standards: https://people.freebsd.org/~phk/funding.html

                    The FAANGS - for now - make such profits that they have the luxury of ignoring the labour market, and paying 3-6x rates for engineers who have demonstrated some unique talent - like authoring an open source project, or living in silicon valley. We’ll see how long that lasts.

                    1. 2

                      The numbers in the article are not FAANGS SV numbers, see the footnote https://words.filippo.io/pay-maintainers/#fn1

                      1. 3

                        True, but it’s the 90th percentile developer salary of three cities with a notoriously high cost-of-living, which is then treated as the lower end of the range. I think it’s no surprise that the author works for a FAANG - very few people would find this kind of calculation indicative of actual salary expectations.

                        1. 4

                          Author here 👋 Note that I use the 90th percentile of all SWE salaries as indicative of the salary of a senior SWE. In my experience, $300k is actually very wrong on the low side for the non-FAANG NYC market, so that suggests the other numbers are conservative too. (Plausible explanations include: less than 10% of engineers are senior, and senior engineers don’t post their salary to levels.fyi. I believe both are true.)

                          It’s true that NYC, Berlin, and London have high cost of living, but salary is not based on cost of living. That’s one of the most amazing things companies managed to convince engineers of. Do you think lawyers get paid based on cost of living? Post-pandemic, the market is flooded of remote positions that will pay the same in Berlin, Hamburg, and Leipzig.

                          1. 3

                            Author here 👋 Note that I use the 90th percentile of all SWE salaries as indicative of the salary of a senior SWE. In my experience, $300k is actually very wrong on the low side for the non-FAANG NYC market, so that suggests the other numbers are conservative too. (Plausible explanations include: less than 10% of engineers are senior, and senior engineers don’t post their salary to levels.fyi. I believe both are true.)

                            I have my doubts about levels.fyi being a representative sample of the market; I’ve noticed that very “boring” companies that are nevertheless major employers (like Atos, CapGemini in the EU, Cognizant in the US) don’t seem to have a lot of data points. Not to mention the complete absence of the thousands of small businesses that employ the bulk of the work force.

                            You’re also implicitly defining “senior” to mean someone who commands a salary in the 90th percentile - in the context of this discussion, I’m fine with that.

                            I think your point about salary makes sense if you read it as “Some OSS maintainers make north of $500k/yr - don’t expect them to quit their day job for $50k/yr.” $1000/month is a “thank you” in the US, but - last I checked - still decent money for a junior software developer in Eastern Europe. Precisely because it’s a world-wide job market, and there’s a wide divergence in salaries, it makes sense to calibrate people’s expectations.

                            For most companies, it makes a lot more financial sense to pay their employees to work on the project (giving them the added benefit of control and in-house expertise) than it is to pay 90th percentile money to someone external. Which is the very thing you’d like to avoid.

                  2. 6

                    Maintainers are worried that taking your money will take control away from them. They, and their communities, don’t want you to impose control over technical decisions. You don’t want that either!

                    For-profit company: We don’t?

                    You want to pay them to keep doing what they are doing, or to dedicate more resources to it. After all, you’re already using their project because they did a good job so far prioritizing and executing.

                    FPC: They did?

                    Governance is a delicate and complex topic, and you want to leave it as orthogonal as possible to funding.

                    FPC: We do?