[HN Gopher] How to Pay Professional Maintainers
___________________________________________________________________
How to Pay Professional Maintainers
Author : FiloSottile
Score : 80 points
Date : 2022-03-21 16:34 UTC (6 hours ago)
(HTM) web link (words.filippo.io)
(TXT) w3m dump (words.filippo.io)
| mfer wrote:
| Professional developers need to be paid. A big question is, how
| do you go about doing it?
|
| Donations don't work. Even recurring ones. Large companies have
| legal hurdles in paying that way. The legal hurdles are very
| large and are legal ones. Things they don't control.
|
| A long tradition has existing among some of setting up a
| business, having invoices, and providing services for the pay
| (e.g., some consulting, logo on the site (marketing), etc).
|
| Setting up a business and handling this this way is how other
| industries have long worked. I think of my local electrician.
| It's not hard.
|
| Just an idea of how to turn an idea into a practical reality.
| jrochkind1 wrote:
| Just to be clear, are you saying... not open source?
| mfer wrote:
| You can have a business, get paid for your work, and have the
| software be open source. So, I'm talking about open source
| software.
| wmf wrote:
| This is currently very very difficult though. I think a lot
| more work is needed to create a replicable business model
| for open source maintainers.
| jrochkind1 wrote:
| Some people can. It's not clear that all the people
| necessary to maintain the current open source ecosystem
| can. Of course, it's not clear they can make a living by
| donations either, true! Either way we're talking about
| something that changes the way resources are currently
| allocated to shift resources from those with budgets to
| those maintaining open source.
|
| But, anyway, since anyone _can_ use open source for free,
| what are open source maintainers going to be invoicing and
| getting paid for? It seems to me it 's _not_ going to be
| maintaining the software itself -- since you can use the
| maintained software without paying, anything you pay for
| maintenance is effectively just a voluntary donation, not a
| straightforward invoice for work.
|
| So whatever you're invoicing for and getting people to pay
| is... something other than maintaining the open source
| software. It seems to me that is not solving the problem of
| "how do you get maintainers paid", in fact it's taking the
| people who are well-placed to be maintainers and
| reallocating their time somewhere else to something they
| can get paid for, and hoping there's enough net profit they
| can keep maintaining in their unbilled hours just because
| they feel like it.
|
| The OP's perspective is more: "How do we get maintainers
| paid for _maintaining_? If you are a company with budget
| who wants to, here 's how. If you instead pay someone for
| doing something _other_ than maintaining, which is often
| what people end up doing (paying for features or what have
| you)... that does not actually make maintaining pay, it
| doesn 't work to make maintaining pay."
| wmf wrote:
| The usual answer is that customers should pay for
| "support" that they will not use (effectively a form of
| insurance), leaving the maintainer free to continue
| maintaining.
|
| In practice I suspect we'll see a lot more license
| changes and hostage source in the future.
| jrochkind1 wrote:
| Getting people to pay for support they won't use sounds
| to me closer to a voluntary regular donation than it does
| the "long tradition of setting up a business, having
| invoices, and providing services for the pay."
|
| I guess it's a way of making a voluntary regular donation
| seem like a traditional invoice to satisfy the
| bookkeepers, but that's not what I thought @mfer was
| getting at. And if it magically worked to produce what
| are effectively donations, we probably wouldn't be having
| this conversation. "
|
| But yes, _you_ are talking about something other than
| open source as the more likely future route, which is why
| i asked @mfer if they were! That 's the straightforward
| way to get people to pay for software -- make it not open
| source, so they have to pay to use it.
| zozbot234 wrote:
| Continued maintenance of the software is also included
| under "support". As are custom feature requests, and
| sometimes marketing/sponsorship (i.e. the company that
| pays for "support" can request to be mentioned on the
| website and in the project documentation). All in all, it
| works quite well.
| onikolas7 wrote:
| Setting up a company is a practical way to offer services,
| especially if you are working outside the US. There is an
| overhead, at least in my case (living in Europe), like paying
| for an accountant, but its well worth it.
| WJW wrote:
| Whenever this topic pops up we get the same few points made
| again, but progress seems to never be any nearer than before.
|
| In the end, the "dream" of being paid for your open source work
| seems to be very similar to having a small SAAS-like business but
| without having to do marketing, customer acquisition or any of
| that boring "business stuff" that comes with running a normal
| company. No leetcoding required! You just write code and somehow
| people will show up and pay you. It's a perfect fantasy for the
| HN audience, which is why articles about it come up so often.
| buro9 wrote:
| Other industries have collections agencies, i.e. the PRS in the
| UK https://www.prsformusic.com/what-we-do/prs-and-mcps
|
| What the PRS does is collect royalties when the works of their
| members (music) is broadcast on TV or radio, performed in public
| (even via a shop tannoy system), stream or downloaded.
|
| Companies wishing to use the music must sign an agreement with
| the PRS to give them an annual fee, and the PRS distributes it as
| fairly as can be based on some sparse data (i.e. sampled radio
| play, reported shop mixes, etc). Most played artists get the
| most, but everyone gets a little.
|
| What if the IT industry did similar?
|
| We have SBOM ( https://www.linuxfoundation.org/blog/what-is-an-
| sbom/ ) as a standard amongst companies averse to making software
| licensing mistakes, and just to have a record of what software at
| what version is running within an infrastructure.
|
| It should be more trivial for this industry to have a collection
| agency that fairly allocates payments to the software and
| dependencies actually in use... than it is for the PRS to do what
| they're doing.
|
| Yes the PRS has legacy, but all legacy starts somewhere. If
| you're running code I've written and still maintain, SBOM will
| tell you so... and a collection agency can come up with some
| payment structure (free to organisations below this much revenue,
| not-free to organisations above so much revenue, etc).
|
| Don't invent something new. Steal the idea and structure from
| those who made it work.
| WJW wrote:
| I'm not sure you want to use the music industry as the pattern
| from which to take inspiration for rewarding FOSS programmers.
| Most musicians don't make more than a couple bucks per month,
| if they make anything at all. Aspiring musicians waiting tables
| is a stereotype for a reason.
|
| Also how would you even start to decide how much postgres gets
| vs colors.js? One is a huge project with highly specialized
| code, the other inserts terminal coloring characters into a
| string.
| wmf wrote:
| Companies like Tidelift are exploring similar models for
| software.
| FiloSottile wrote:
| There was a pretty good discussion yesterday on this in the
| comments of a related article. I'll repost below my comment which
| summarizes the two articles I wrote, but I recommend checking out
| that thread, as it covers a lot of supporting and dissenting
| directions.
|
| - https://news.ycombinator.com/item?id=30741702
|
| Open Source volunteerism is the result of the early hacking
| culture and of what makes the Internet special: people choose to
| experiment and share their work, and their work can reach every
| corner of the world. It has no significant parallel in other
| industries, it's beautiful, and I owe it my career.
|
| However, it's not a sustainable, fair, or effective foundation
| for an industry with the responsibility to power modern society.
| We need the critical role of Open Source maintainer to
| professionalize. This is most likely to happen through capture by
| large intermediaries, but I wish to see it happen through the
| formation of a serious professional role, organized independently
| or in small firms, like lawyers.
|
| This will require changes both from the maintainers [1] (become
| legible, get a LLC, send real invoices, offer guarantees) and
| from companies [2] (pay the maintainers, pay them real money, pay
| for maintenance, and keep paying them).
|
| [1] https://words.filippo.io/professional-maintainers/
|
| [2] https://words.filippo.io/pay-maintainers/
| baby wrote:
| I'd be interesting if I could, today, look at my dependency tree
| and decide to donate a number X that would be shared amongst all
| the dependencies that have declared a donation API (perhaps a
| cryptocurrency address). This way I contribute to all of what I
| depend upon, making my own part of the ecosystem healthier.
| Sean-Der wrote:
| I have had offers to be paid to work on specific things for
| github.com/pion/webrtc and github.com/pion/dtls. I took one and
| it wasn't as great as I thought it would be.
|
| I really value the autonomy/independence I have now. I enjoy not
| having to make compromises. No deadlines to meet, no business
| goals and no creating stories for promotion. Instead I make the
| software as good as I can.
|
| Working a job unrelated to your Open Source project is the best
| place to be. You will probably make more money. You don't have to
| worry about clients paying on time. You don't have to worry about
| things like health insurance or 401k.
|
| Open Source is also great for the resume. Since it is all public
| you have a body of work that makes it much easier to get another
| job.
| ldoughty wrote:
| I find it actually difficult to do this.
|
| When we engaged OpnSense, they had a website, had an email for
| support/service inquiry, and even a website to "buy support
| subscriptions"...
|
| This made the process VERY easy to get through our legal hurdles,
| and "buy 20 hours/year in support" (which we likely won't use
| even half of)... we also contracted a professional service to
| simply sit down with a developer to go over how they intend the
| image to be created/automated... while we could figure this out,
| it was another opportunity we could classify as a professional
| service to get through our systems. This is certainly not "paying
| them what they are worth", by any means, but our budget allowed
| us to spend a few thousand a year at least.
|
| Apache, on the other hand, has been difficult... We want to
| support a specific project, and would like a similar
| relationship, but the developers are not listed anywhere, and
| there's no support mechanism except through 3rd parties. It seems
| your best bet is to put out a request, and see if they are an
| active member of the project, and try to negotiate with them
| individually? That's not going to be an easy sell to management.
| FiloSottile wrote:
| I love this, it's essentially a case study for the companion
| article addressing maintainers instead of companies:
| https://words.filippo.io/professional-maintainers/
|
| We need both sides to shift for this kind of transactions to
| become commonplace.
| pphysch wrote:
| I don't think digital public goods are economically that
| different from physical public goods.
|
| Expecting private companies to fund the (micro)infrastructure
| that enables their business has never been a solution. It's a
| libertarian pipe-dream, leading to a spaghetti of "toll roads"
| and service outages.
|
| The obvious, time-proven solution is to fund this infrastructure
| through an accountable, transparent, public institution. There
| should be a central source of truth where you can check if X
| project is being publicly funded, at least within a particular
| jurisdiction. Grants would be simple: $X over Y years for
| "maintenance and general development", then reevaluate after Y
| years.
|
| If the federal government won't do it (although they already
| literally do this for government software projects...), then at
| least a forward-looking state could get things started.
| "libfoobar is officially a Texas Digital Public Good..."
|
| But leaving this up to the good-will of private, profit-seeking
| companies will simply never work in the long-run. Cost-cutters
| will inevitably come and ruin it, with no recourse for the
| maintainers. They will be the first to be "laid off".
| mholt wrote:
| I also wrote about this in some depth recently (but for
| maintainers): https://matt.life/writing/the-asymmetry-of-open-
| source (discussion:
| https://news.ycombinator.com/item?id=30706650)
|
| I'm glad Filippo is de-stigmatizing high-tier sponsorships:
|
| > 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.[1]
|
| > ...
|
| > $1,000/month without benefits is a nice way to show
| appreciation, but won't achieve any other goals.
|
| Smaller sponsorships do still contribute towards an overall
| paycheck, but aren't sufficient alone. While the majority of my
| sponsors are at $25/mo. (I should kindly mention that Filippo is
| one of them! For which I am very grateful.), I have tiers for
| $250, $1000, $6000, and $11000 per month as well [1]. I only have
| one or two total sponsors among the higher tiers. Currently, the
| majority of my expenses are covered by a single executive sponsor
| (ZeroSSL). The rest of my expenses are covered by independent
| professionals or small companies (which I also rely on -- thank
| you!) Without _both_ the higher-tier and lower-tier sponsors, I
| would not be able to sustain a living working on Caddy.
|
| (By the way, sponsorships drop out on a regular basis, so it's
| always important to sign on new sponsors regularly.)
|
| So when I say to large companies: "You need an enterprise
| sponsorship to support your business use of Caddy," I mean it! It
| would take hundreds of $25/mo. sponsors to cover living expenses
| and match a senior engineer's salary, or it would only take a few
| enterprise sponsorships -- and it's way more affordable to
| sponsor along with a few other large companies than it is to
| bring the expert in-house exclusively. Ideally, we'd achieve a
| healthy mix of lower-tier and higher-tier sponsorships.
|
| Maintaining a large and complex project like an extensible,
| general-purpose web server is a lot of work and requires
| expertise I've spent almost a decade tediously accumulating. I
| don't want to have to find other work right now, and with
| hundreds of thousands of dollars of their revenue per hour
| relying on a web server that a student designed and developed
| after-hours in his senior year of college and spent years
| mastering since then, large companies depending on the project
| shouldn't want me to leave it either!
|
| After I got married last month, our open source sponsorships are
| suddenly supporting a family of five. Yet another reason --
| albeit a more personal one -- that I strive to reach sufficient
| sponsorships: now I have something I care more about more than
| software.
|
| I really love working on Caddy every day. I hope it continues as
| companies continue to sponsor its development.
|
| [1]: https://github.com/sponsors/mholt
| daqhris wrote:
| What about a centralized database (i.e blockchain) of all
| maintainers who get rewarded recurrent revenue in digital money
| (i.e. crypto) for their projects?
|
| In all seriousness, the author and his project Filippo are on the
| right track to help bring income to humans maintaining open
| source software. Another team doing a similar stellar job in the
| crypto sector is GitCoin and their grants to software devs.
| that_guy_iain wrote:
| After a quick read, my take on this. This basically says we need
| commercial software that companies pay for. It's just that people
| are so used to open source and developers have been banging on
| about how open source is good that no one really wants to admit
| that open source isn't all that good, we have the 1% of projects
| that everyone points to Linux Kernel, Kubernetes, etc but the
| reality is most open source libraries and applications are under-
| maintained. There are lots of battle tested well used production
| ready libraries that are being used by thousands of companies
| that have open issues and open pull requests and no one has even
| responded to. The whole "you can fix it yourself" is great until
| you realise that often means "you can fork it and fix it and
| maintain your own version"
| mfer wrote:
| It's more complex than that...
|
| 1. There are business that maintain open source software,
| today. That are paid maintenance. This can work for some cases.
| This can even work for libraries as some already do this.
|
| 2. Linux is a good example. There are legal organizations that
| surround it. From Linus to most of the contributors. People are
| paid for the work. Through legal organizations. With contracts
| involved. It's not an example of open source with volunteers
| doing the work out of the goodness of their heart.
|
| 3. Open source software can be great. But, just like an
| electrician doesn't just do electrical work in order to make a
| living... the same applies to open source software development.
|
| 4. There is a lot of open source maintained by companies that
| is not their core business value. This is reliable and
| production ready software. Sometimes people do make change
| requests to fix or improve these.
| that_guy_iain wrote:
| > 1. There are business that maintain open source software,
| today. That are paid maintenance. This can work for some
| cases. This can even work for libraries as some already do
| this.
|
| This is true, but in my experience they end up complaining
| about the same thing. Competitors using their code to make
| money. Often this results in them becoming non-open-source,
| for example, Elasticsearch. I personally think the approach
| that Elastic has taken is the right approach and is what we
| should embrace instead of the whole open source is great and
| we should all do open source to help our careers.
|
| > 4. There is a lot of open source maintained by companies
| that is not their core business value. This is reliable and
| production ready software. Sometimes people do make change
| requests to fix or improve these.
|
| These are also often under-maintained.
|
| > 3. Open source software can be great. But, just like an
| electrician doesn't just do electrical work in order to make
| a living... the same applies to open source software
| development.
|
| I highly suspect the majority of them only do electrical work
| to make a living.
| mfer wrote:
| > Often this results in them becoming non-open-source, for
| example, Elasticsearch.
|
| It's important to note that Elastic was a VC funded company
| that is now a listed public company trying to make open
| source maintainership their businesses as a high growth
| business. This is different from being a sustained
| maintainer making OK to decent compensation for their work.
|
| The type of business matters. Is it high growth (or VC
| which is high growth) or is it consistent maintaining.
|
| > These are also often under-maintained.
|
| Sometimes they are and sometimes they are not. Are there
| any stats on this?
|
| > I highly suspect the majority of them only do electrical
| work to make a living.
|
| My point is that they don't ONLY DO electrical work. They
| have legal businesses, they do invoices, they handle
| accounting and money comes and goes, etc. They don't get to
| forget how businesses and finances happen while hoping for
| donations.
| zozbot234 wrote:
| We should all embrace proprietary software? The approach
| Elasticsearch and other SaaS providers take is anti-freedom
| and inherently harmful to the "right to fork", which is
| precisely what makes open source more long-term sustainable
| and resilient than any garden-variety proprietary package.
| lazide wrote:
| Yeah - but having worked in many companies over the decades,
| ALL software is this way and most commercial software is even
| worse.
|
| The difference is, you can't fork and fix it yourself when it's
| closed source from someone else. and a surprising amount of
| code running in every company it's 'someone else's' code even
| when it's internal and part of the same company.
| onebot wrote:
| I would love to know how to recruit a professional maintainer.
| This is a tremendously difficult skill set.
| david_allison wrote:
| Suggestions off the top of my head (I'm concerned this sounds
| like a list from a prima donna)
|
| * Specifically mention that you're after someone with
| nontrivial open source experience/maintenance experience and
| you'll accept it in place of Leetcode
|
| * Some inkling that you've thought about titles/HR considers
| "maintainer" as experience
|
| * Provide the expected time commitments from interviews
| upfront. Likewise for compensation.
|
| * Expect part-time or contract work. If full-time, explicitly
| allocate time to their OSS.
|
| * Remote, if part-time or contracting
|
| * Async friendly. I've had 1 "real-time" meeting in OSS
| (total).
|
| * Post a spec/contact details in a reply to this comment, or
| "Who is Hiring"
| kkfx wrote:
| The best maintainer is one who need _personally_ to have a
| certain software maintained, that 's why FLOSS tend to have a
| mean better quality and less refinements than commercial
| software.
|
| Honestly my personal opinion is "when labeled 'professional' or
| 'enterprise' is something similar to Star Trek Enterprise ship,
| something that keep having terrible troubles, extremely bad
| design (for instance a single 'reactor') etc"...
| 0xbadcafebee wrote:
| I think we need a valuation of the software. If you can show its
| real value to a business it's much easier to get a business to
| add a line item to pay for it. Defining the risk to a business of
| the software being abandoned is another good way to make a case
| for funding.
|
| After that I think it's worth having a new corporate funding
| _method_. I think there should be a "co-op patreon", where the
| software funding requirement is presented, and companies join the
| patreon group and equally share the cost of supporting it,
| adjusted by revenue amount. In this way both a mom-and-pop and a
| FAANG can contribute fairly to the project. The more
| organizations that join, the less they have to pay, as once the
| funding cap is reached, no more money is needed, and the cost is
| spread across more and more orgs. If every company that used
| _curl_ joined such a group, they 'd all be paying pennies.
|
| So, next steps would be: 1. Standard process to
| evaluate software value 2. Standard provess to evaluate
| software risk 3. Stock letter to use in companies to
| propose funding 4. "Patreon" clone that enables corporate
| co-funding adjusted by revenue
| lazide wrote:
| The issue is quantifying these things. Companies that provide
| commercial support provide (usually) some kind of SLA. If
| software may have a vague risk of a future issue or may be
| abandoned, that's pretty hard to weigh if it is worth $x
| dollars unless everyone is already doing it and it's 'industry
| best practice', which we aren't close to yet.
| mothsonasloth wrote:
| I like the way JHipster does it:
|
| - Organisations give money that goes into Jhipster organisation
| coffers
|
| - Committee / treasurer manages this chest of money
|
| - Bugs are found and assigned bounties depending on how severe
| they are
|
| - PRs are made for those bugs, when accepted and merged the money
| is released
| hinkley wrote:
| This is my theory: we have missed a critical element of _how_
| FOSS got adopted in the industry in the first place. That blind
| spot explains a lot of the problems we have had with getting
| compensation to FOSS authors, which has created a whole other set
| of problems for us to deal with.
|
| In the middle of the S curve for adoption, software development
| teams were struggling with the fact that someone in finance
| laughed at the idea of spending money to make money. R&D is a
| cost center, and anything that reduced costs would make life
| better for the company. Well, any costs except labor, which are
| some magic other shade of money that can't tell that you just
| spent 1000 man hours on something that should have taken 300 but
| you first had to squeeze another application onto aging hardware
| that was slower than what some of the developers have at home.
|
| In some cases these people were power tripping. They seemed to
| enjoy being able to say 'no' to any requests, able to use their
| purchasing veto power to make you do what they want you to do.
| Everyone had one of these stories. Many had one about the current
| employer.
|
| Then along came Open Source. When you said, "I want to use X" and
| this person said, "We're not paying for that, no," you could
| cheerily shoot back, "Oh but that's the best part, it's free, so
| you don't have to pay for it. Have a nice day!" and tralala your
| way back to your desk while they are left trying to think of a
| way to force you to do things their way. That is why it's used
| everywhere. Because nobody could stop us.
|
| So we've democratized the power dynamic quite a bit (you still
| have general managers forcing teams to use Oracle because
| otherwise they have to explain why they have been sending that
| much money to Oracle if half the applications are running on
| Postgres, so they pull the dick move of banning Postgres), but
| that money problem is still there, as it always has been. If I
| can't buy copies of TeamCity, which is commercial software with a
| commercial license, I sure as hell can't get the company to send
| $100 with no contract to some internet randos just because I say
| they're saving us a million dollars a year.
|
| You can't educate your way into fixing that problem. People have
| been trying literally for decades. There's a plumbing problem
| here, and until that gets fixed you can plead with people all you
| want to fund OSS, but it's not going to happen.
| asah wrote:
| As a mid-level manager, I'd just whip out my personal credit
| card and expense it. In 20 years, nobody blinked. Ditto with
| taking a tax deduction from the IRS for my personal consulting
| work, which depends on FOSS.
|
| IMHO the issue is that users are lazy and have truly-zero risk
| tolerance, and that in turn means that FOSS developers need a
| lot more money per donor, which in turn means fewer donors.
|
| I'd like to see a single consolidated donation per unit time,
| that's then divvied up __based on your usage__ i.e.
| homebrew/apy/yum nags you from time to time and makes it one-
| click to make a decent-sized donation to the 100+ projects you
| actually use.
|
| (obviously, there's disagreement about what "use" means, but
| the UI would make it easy for the donor to make adjustments...)
|
| (and yes, I'm volunteering to work on something like this
| and/or help fund it)
| [deleted]
| jka wrote:
| Interesting - so, to reinterpret: are you saying that one of
| the significant changes that open source brought about has been
| to remove purchasing approval barriers for software usage?
|
| ...and that we're stuck in a local minima where we now have to
| get over other, similar approval barriers to send money back
| towards open source projects? (in the case of projects that
| accept funding, at least)
|
| (it's possible I've misinterpreted; and, for what it's worth, I
| think there are other reasons that FOSS has succeeded in
| addition to what you say - but I like that way of looking at
| the current landscape)
| hinkley wrote:
| In a nutshell, yes.
|
| I observed a number of people say one thing in a group
| setting but would confess to other things off the record. The
| purse string issue was high for a lot of people, but as you
| say that wasn't the only motivation.
|
| I think too that we oversold the Enlightened Self Interest
| value to the company in open sourcing internal tools. People
| worked hard on code that they didn't want to have to write
| again somewhere else, especially not several times. My
| current and future job satisfaction are elevated by
| convincing my bosses to free the code, the Greater Good is
| also improved by doing so. Nothing makes me want to leave
| like feeling trapped, and any work I do that has value past
| my expiration date is a big part of feeling like being here
| still is a choice.
|
| But I think only a few companies ever enjoyed the fruits of
| that effort to the degree that we were all telling them they
| would. Sun Microsystems in particular. But the industry
| benefited _enormously_ , so history will probably be fairly
| kind.
| JonChesterfield wrote:
| It is _really_ annoying to write the same code repeatedly
| because the last time was inside some other company,
| especially when there's no plausible IP involved.
| hinkley wrote:
| Especially when you make half of the same mistakes every
| time. No argument here.
| xxpor wrote:
| The funny thing is, every eCommerce site already knows this
| at least implicitly. We've all heard the "every X ms of
| additional latency on the site reduces our conversion rate Y
| bps". Adding friction to anything means it's much less likely
| to get done.
|
| Even for commercial software, if it were easy to purchase,
| I'd still have to figure out how to make sure we comply with
| the licensing, get the key into the server, figure out how to
| deploy it (and not be able to inspect the software to see how
| it works if I need to).
|
| Or I can just go to github, make sure it has an acceptable
| license, and run import-from-pypy foobar==1.0.
| hinkley wrote:
| I don't think Jetbrains would be where they are today if
| not for personal license that grants the right no use the
| software on as many machines as I like. When it was
| introduced it cost just slightly more than 3 technical
| books, and I knew a couple of people who used that math to
| convince others to switch to Jetbrains.
|
| That license is worded specifically for me to use my
| private copy at work without exposing my employer to
| liability.
|
| It's surprising to me that more organizations haven't
| followed suit. But many of these tools run either on the
| server or on a CI/CD machine so I'm not sure how you'd work
| that.
| a_e_k wrote:
| This is one of the things that sold me on the Affinity
| graphics suite. Their license [0] works the same way for
| purchases by private individuals.
|
| [0] https://affinity.serif.com/en-us/licence/
| cheesedoodle wrote:
| An OSS project that a previous company heavily relied upon,
| pleaded that they needed funding or would seize maintenance. As
| the project manager at the time, I told the R&D manager to
| start funding this OSS project. In return, we'd get maintenance
| and features that we otherwise would handle in-house. Roughly a
| 10kUSD/y handout from a Fortune 500. "How much do we pay
| today?", asked the R&D manager, "Nothing", I said, "its open
| source". "Then we will continue to pay nothing". So many
| companies take OSS projects for granted and as a once OSS core
| developer, I have seen many sides of this. Don't expect anyone
| to pay you for the work you are doing, and if you find your
| self not having the capacity to continue, try to see if there's
| any other maintainer ready to continue it for you, if not, even
| if it hurts, just leave it alone...
| WrtCdEvrydy wrote:
| > "How much do we pay today?"
|
| "Not as much as we'll pay replacing it"
| cheesedoodle wrote:
| Well, yes. But clearly, the 3rd party project is not the
| core business but would be if there was no alternative. The
| company would just develop it them self, if deemed
| necessary. The idea is that the knowledge would be retained
| within the company instead. The term "its free real estate"
| comes to mind.
| hinkley wrote:
| This is the game, and people who don't like it still play
| it, which makes it worse.
|
| Boss knew we were using our integration box for customer
| demos. I don't know how many times I explained that the
| entire team would be blocked by 1 pm on demo day, and some
| people would be blocked as early as 10 am, for want of a
| cheap box. I had to make a chart that showed man hours lost
| versus the cost of the new machine. Six weeks. The new
| server would pay for itself in six weeks. He said something
| sheepish about how he thought I meant a '"server" server',
| not a workstation class machine. Still don't know what he
| was thinking. A "server" server still would have paid for
| itself in six months, and he would have the luxury of me
| not bitching at him every time he forgot why almost
| everything that didn't get done on a Thursday slipped to
| Monday afternoon and asked me again about slippage.
| hinkley wrote:
| While this plays out with OSS quite a bit, it's not limited
| to just free software.
|
| You are almost always spending more on an early adopter than
| they are paying you for your software, but typically that's
| with the understanding that you are re-selling those
| solutions to new customers.
|
| That hasn't always been the case. I've worked at a couple of
| startups where one of our customers was exuberant about how
| critical we were to their roadmap, but part of why they were
| so happy was because they were getting a sweetheart deal, and
| we couldn't figure out how to tell them no, or sign them to a
| more lucrative contract because the one they have is already
| so nice, they'd be fools to sign a different one.
|
| And then they go pikachu face when we either went under or
| got sold to someone whose career (and probably no small part
| of their job satisfaction) was built around saying No if you
| were lucky, and Fuck you, Pay me if you weren't.
| RcouF1uZ4gsC wrote:
| > Pay them real money. In the order of what they could make as
| senior engineers.
|
| What advantage is that to the company over just hiring them and
| having them continue to work on the open source project. From the
| company's perspective, not only does that cover paying for
| maintenance, it also gives them far more control over the
| direction of the open source project by directly employing the
| main contributors.
| wmf wrote:
| A single customer doesn't have to pay the entire cost. Twenty
| customers paying $10K/year provides a full-time income for the
| maintainer without the inequality of one customer paying for
| all the others.
| wila wrote:
| You are assuming that the OSS engineer is available for hire as
| an employee.
___________________________________________________________________
(page generated 2022-03-21 23:00 UTC)