51–60 of 113 posts
I wish more open source projects had an "enterprise" plan with a few inconsequential features and maybe priority support - just enough to justify a line item on a tech org's budget.
How do you provide these pay-only features on an open source project? And who is doing the support? It sounds like you are envisioning something like Red Hat.
I wish more open source projects had an "enterprise" plan with a few inconsequential features and maybe priority support - just enough to justify a line item on a tech org's budget.
One of the reasons why devs at enterprise scale companies like OSS so much (except GPL, obviously) is because trying to purchase anything is a nightmare.
If you've worked at such an org, you know exactly what I mean, otherwise you might even find it difficult to believe. Purchasing anything can take several months, with hundreds of manhours wasted on call, meetings, legal review, approvals from random people etc. And if you're the one that initiated it, you'll be the poor sod that has to keep pushing that boulder up the hill all the time, otherwise it just stalls forever. It's honestly should destroying.
Earlier quoted context omitted.
That would only work for the largest companies hiring for the largest FOSS projects, without some sort of independent administration.
Hiring a full time dev just for FOSS submissions probably isn't justifiable to most employers, but diverting just a little employee time seems reasonable, especially if it's directed at bugs/feature improvements impacting the devs' use of the thing.
I wish more open source projects had an "enterprise" plan with a few inconsequential features and maybe priority support - just enough to justify a line item on a tech org's budget.
Ah, I wish it were so simple! One of the reasons why devs at enterprise scale companies like OSS so much (except GPL, obviously) is because trying to purchase anything is a nightmare . If you've worked at such an org, you know exactly what I mean, otherwise you might even find it difficult to believe. Purchasing anything can take several months , with hundreds of manhours wasted on call, meetings, legal review, appro…
Businesses teach accounting and finance, very numbers-oriented subjects, as a minimum, so this is not entirely outside of the wheelhouse of business schools.
And yet this near-universal problem of software procurement continues across enterprises, a problem traced basically to equally universal teachings on cost control policies and other nuts and bolts that come out of explicit teachings of b-schools and the general literature of running businesses.
Since I posted a wandering treatise on american antiintellectualism and the fundamental lack of cool of the "nerd", and how b-schools want to appear as cool, cutting edge producers of captains of industry (that adopt learning nerdy accounting as a necessary hurdle to get as much money as possible), I doubt they will properly pivot anytime soon.
I've often thought companies should provide say $500/month for each of their developers to pay out to the open source projects of their choice. One month an employee might give it to Vim, another to Curl. I think a discretionary scheme like that would buy a lot of good will from the employees, potential hires and the development community.
I've often thought companies should provide say $500/month for each of their developers to pay out to the open source projects of their choice. One month an employee might give it to Vim, another to Curl. I think a discretionary scheme like that would buy a lot of good will from the employees, potential hires and the development community.
I've often thought companies should provide say $500/month for each of their developers to pay out to the open source projects of their choice. One month an employee might give it to Vim, another to Curl. I think a discretionary scheme like that would buy a lot of good will from the employees, potential hires and the development community.
Google does this (each employee can nominate 3 people for $250 each per round of funding. Recipients are limited to $500/year due to tax) [0] [0] https://opensource.google/docs/growing/peer-bonus/
Cool, that’s easy. So each company should donate 200 hours of work to open source projects. Encouraging more volunteer time is better than trying to collect and allocate cash. And better improved OSS. I think.
During heavy periods this year I had ~20-30 code reviews per day.
There's a balance between money and contributions. You can't just throw bodies at a problem and say it's better than any alternatives.
I think this is good will for sure, and 2k is a rounding error to the cost of most enterprise software, but the real problem with (most) FOSS is the lack of clear structure or organization in terms of payment. Not only who gets paid, but also how much to pay, how to quantity roles and work, spending if necessary, etc. That’s the real problem/opportunity for someone like Gratipay.
2k per engineer ... that's more than a rounding error. It'd be interesting to compare to per-seat licensing for commercial software. Anyone have examples?