It is curious that users would downvote/flag our post yesterday but not Colin's post today, which begins, "Yesterday I read a great article from Sentry". I agree it's kinda shouting into the wind to complain. Oh well. :)
2,157 karma · joined April 5, 2011
https://news.ycombinator.com/item?id=1890574
https://www.technologyreview.com/2010/11/15/120320/should-co...
I don't find the original in archive.org or archive.is. :-/
TIL, thanks! Found this: https://www.networkworld.com/article/2227761/a-tithe-for-ope.... Looks like the original blog post is gone. Wonder if Gabe wants to revisit. :thinking:
One of our goals is to keep the parameters to an absolute minimum, to aid in adoption. The simpler we can keep it the more easily it will get picked up, is the thinking.
This sets up a false dichotomy. We _do_ have active relationships with the developers of our most important and fundamental projects.
> establish a business relationship to satisfy what open source licenses leave lacking
We do this. We pay on contract for work we need. This is separate from that.
> the results they are hoping for
The result we are hoping for at a company level is to give a more-or-less fair amount of money in return for the value we have received over the past year from sponsorship-seeking Open Source maintainers. I think of this as IOR instead of ROI—we are paying for value already received. This result is achieved. :)
Our hypothesis is that through social validation we can encourage other companies to follow suit, and if we're successful enough this could create opportunities that don't exist now. The $25k/yr scenarios you describe would be the bottom rung of this. FOSSFunders.com is where we're pursuing this. Wish us luck! :)
Cheers!
[I'm the post author.]
Curious in this. 15k is on par with what we give to foundations such as Python, Django, Rust and OpenJS. Is that the right anchor?
Another angle: Which deps should we take money away from to give more to rrweb?
[I'm the post author.]
> Yesterday we announced that Codecov is now “Open Source”, and we messed up in two ways:
> - We wrongly used the term Open Source; while unintentional, we should have known better
> - We let our emotions get the best of trying to explain our position, rather than stepping back and addressing the problem
> I want to talk about both of these, how we made the mistake, why it’s important to us, and what we plan to do about this to improve the conversation in the future.
> Yesterday we announced that Codecov is now “Open Source”, and we messed up in two ways:
> - We wrongly used the term Open Source; while unintentional, we should have known better
> - We let our emotions get the best of trying to explain our position, rather than stepping back and addressing the problem
> I want to talk about both of these, how we made the mistake, why it’s important to us, and what we plan to do about this to improve the conversation in the future.
Also feels like we'd have to take this conversation to a video call or something to make any further progress.
[disclosure: I'm Head of Open Source at Sentry, which owns Codecov.]
This is fairly accurate, though there are a range of possible outcomes we would be satisfied with.
> my theory about embrace/extend/extinguish seems to be as accurate as I thought.
This is confused. Embrace/extend/extinguish means to initially participate in an open standard and then extend the standard in such a way that the non-extended version is sidelined.
What is the standard in this case? The Open Source Definition? What is the extension? A limit on commercial reuse in the OSD itself? A widely endorsed time-based license scheme such as BSL? Let's say this came to pass (use your imagination :P ). What is extinguished thereby? The OSD still stands. The supposed extinguisher is _more_ committed to the standard, not less. Other companies that use even weirder licenses like SSPL and ELv2 and now HFOIL :rolling-eyes: are likely brought back within an easier to reason about system and we can all stop arguing about this a couple times a year. There is net _more_ open source software in the world, in both the strong (current) and weak (time-delayed) sense.
That seems better to me than the current situation, and if in your view that is a change in the essence of open source, then yes, let's change open source. Change or die.
[disclosure: I'm Head of Open Source at Sentry, which owns Codecov.]
1. The only way for businesses to release their core products under OSI-approved licenses is through a time delay such as the BSL.
2. It's good for businesses to release their core products under OSI-approved licenses.
3. Therefore, some concept of time-delayed release must be included in the definition of open source.
I'll concede that this is an evolution or refinement of the definition of open source, but not a change to the essence.
[disclosure: I'm Head of Open Source at Sentry, which owns Codecov.]
[disclosure: I'm Head of Open Source at Sentry, which owns Codecov.]
No, but Apache 2.0 is, which is what we revert to after three years. The better analogy would be, "I've decided to become vegetarian, starting in three days." But then actually legally guaranteeing that you'll follow through vs. always pushing it off into the future which is what it sounds like with the vegetarian example, I know I wouldn't believe myself if I said that. :D
[disclosure: I'm Head of Open Source at Sentry, which owns Codecov.]
> We sometimes call this a "folk practice" in the product design world, which is the idea of someone's using something in a way that is not really quite how it was intended or designed for but they're pointing the way towards their true problems.