How ‘open’ should your open source be?(github.com)
github.com
How ‘open’ should your open source be?
https://github.com/readme/featured/how-open-is-open-source
66 comments
Free Software as explicitly anti-corporate is not something Microsoft likes to remind itself of.
Free/Libre Software is not anti-corporate, it is pro-user's freedom to use, modify, sell and improve such software
A huge part of the GPL vs BSD wars were fought explicitly around balancing pro freedom vs preventing corporate takeover (and the various spawned GPLs are even more explicit).
It's anti-corporate-abuse-of-users, which in Microsoft's case is exactly the same.
It’s anti-corporate by purpose, but its philosophy is in opposition, or maybe just neutral, to corporate software sold for profit.
If floss takes over the world there’s no place for corporate software.
But I think it’s a false dichotomy and we will be a pluralistic state (like we are now) where there’s free/libre software that’s really popular and also corporate software where no one wants to volunteer their time to build.
But I understand how Microsoft could think that GPL is a threat to them. Linux did kind of kill (is killing) their dream of every server in the world running windowsnt.
If floss takes over the world there’s no place for corporate software.
But I think it’s a false dichotomy and we will be a pluralistic state (like we are now) where there’s free/libre software that’s really popular and also corporate software where no one wants to volunteer their time to build.
But I understand how Microsoft could think that GPL is a threat to them. Linux did kind of kill (is killing) their dream of every server in the world running windowsnt.
It's not just you. I think it is with great generosity that this article can be described as merely ignorant.
> I realise that this is intentionally a very highly-compressed version of history, but
Author here. As you say, it's a highly-compressed version of history. Getting into the finer points of the evolution of open source wouldn't really have had any bearing on the rest of the article.
Author here. As you say, it's a highly-compressed version of history. Getting into the finer points of the evolution of open source wouldn't really have had any bearing on the rest of the article.
Honestly, it is not possible to perceive it as being written in good faith.
I suppose we'll just have to respectfully disagree about which precursors are "finer points of evolution" and which are "major foundational cornerstones" of Open Source.
It was definitely a major thing. But in this discussion, the main points we even focused on about the characteristics of open source when defining it were the same as the FSF:
"When we call software “free,” we mean that it respects the users' essential freedoms: the freedom to run it, to study and change it, and to redistribute copies with or without changes."
The bigger part of the "how we got here" was actually that GitHub ended up creating this ecosystem where collaboration was so open and easier to use to a larger population that we ran into an unintended consequence: maintainers being overwhelmed.
The overall history was intentionally a very quick, broad brush stroke to move into the points that pertained to someone feeling like they had to close their project to contributions.
"When we call software “free,” we mean that it respects the users' essential freedoms: the freedom to run it, to study and change it, and to redistribute copies with or without changes."
The bigger part of the "how we got here" was actually that GitHub ended up creating this ecosystem where collaboration was so open and easier to use to a larger population that we ran into an unintended consequence: maintainers being overwhelmed.
The overall history was intentionally a very quick, broad brush stroke to move into the points that pertained to someone feeling like they had to close their project to contributions.
Highly compressing out the most important part of open source is kind of funny. Especially since you call out the person who arguably coined the phrase.
Also, this is your readme so it’s not like you have some editor pressuring you to cut down.
Also, this is your readme so it’s not like you have some editor pressuring you to cut down.
It's tricky. Like there's real benefits to allowing contributions sometime.
I was profiling some code and discovered that OpenNLP uses StringBuffer where it should use StringBuilder in a few places, and for those not fresh with Java, the two work the same except StringBuffer is a thread safe construction that is very slow and largely considered a deprecated vestige of Java 1.0, and it was used in a way where it didn't need to be thread safe and wasted significant resources on memory barriers and lock acquisition. This code is real hot so monkey patching the code to use StringBuilder instead made my code run like 10x faster.
Happy to have figured a performance issue, I wanted to tell them that the might want to change the letters 'ff' to 'ild' in this one place. But I just couldn't figure out how to contact these people and let them know about this trivial 5 character change patch that would make their code tangibly suck less. Like they wanted me to sign up to a jira instance that wasn't publicly available to create an issue so that I could create a github pull request or some such. Real byzantine. Couldn't even find any contact information to the developers. It's a bit of a shame.
Overall I wish there were more good role models for open source projects that aren't like a text editor or some small library. I've had serious trouble figuring out how to operate my own projects that didn't fit the mold.
I was profiling some code and discovered that OpenNLP uses StringBuffer where it should use StringBuilder in a few places, and for those not fresh with Java, the two work the same except StringBuffer is a thread safe construction that is very slow and largely considered a deprecated vestige of Java 1.0, and it was used in a way where it didn't need to be thread safe and wasted significant resources on memory barriers and lock acquisition. This code is real hot so monkey patching the code to use StringBuilder instead made my code run like 10x faster.
Happy to have figured a performance issue, I wanted to tell them that the might want to change the letters 'ff' to 'ild' in this one place. But I just couldn't figure out how to contact these people and let them know about this trivial 5 character change patch that would make their code tangibly suck less. Like they wanted me to sign up to a jira instance that wasn't publicly available to create an issue so that I could create a github pull request or some such. Real byzantine. Couldn't even find any contact information to the developers. It's a bit of a shame.
Overall I wish there were more good role models for open source projects that aren't like a text editor or some small library. I've had serious trouble figuring out how to operate my own projects that didn't fit the mold.
I kind of think organic projects need to be a little shielded from the entire world to grow.
To contribute to a walled garden you need to prove to the gardners that you're not going to destroy everything they've strived towards, even if what you're proposing is more efficient or better. Make friends with the Gardner's first, talk to them on their level, prove to them you're willing to jump a little. If you stake nothing of yourself but demand to be let in to let your contributing be known there's a risk that the whole project will lose focus, sure not after first or the second, but maybe after the 10th or 20th contributor with their own destabilising vision of how things should work.
Open source projects need to be democracies from the get go in order to fascilliate such chaos. Otherwise, contributors need to prove that they're at least a little sympathetic to the long term goals of the original authors.
To contribute to a walled garden you need to prove to the gardners that you're not going to destroy everything they've strived towards, even if what you're proposing is more efficient or better. Make friends with the Gardner's first, talk to them on their level, prove to them you're willing to jump a little. If you stake nothing of yourself but demand to be let in to let your contributing be known there's a risk that the whole project will lose focus, sure not after first or the second, but maybe after the 10th or 20th contributor with their own destabilising vision of how things should work.
Open source projects need to be democracies from the get go in order to fascilliate such chaos. Otherwise, contributors need to prove that they're at least a little sympathetic to the long term goals of the original authors.
The other replies defends the walled garden approach but I agree with you. Most of the time I patch or fork the project to suit my needs. But sometimes there's little things that would definitely help if it's merged to the mainline. Note: for others, not for me. I already have my own fork.
So my patience to go through the hoops is very small. Since I'm only doing it because I think it'll be beneficial for others.
It doesn't matter for me if it doesn't get merged or even read by the maintainer. But in cases like you mentioned, it's just such a shame.
So my patience to go through the hoops is very small. Since I'm only doing it because I think it'll be beneficial for others.
It doesn't matter for me if it doesn't get merged or even read by the maintainer. But in cases like you mentioned, it's just such a shame.
...They wanted me to sign up to a jira instance that wasn't publicly available to create an issue so that I could create a github pull request or some such. Real byzantine. Couldn't even find any contact information to the developers
To me, all this seems like a reasonable filter.
Not much of a barrier when if contributing to this particular code base was of high personal importance.
I mean, if that's the way the team works. That's the way it works and if it isn't the way a particular person wants to work then perhaps they are not a good fit with the team.
[This is not intended as snark] If the project is important to you and the team doesn't work in a way that works for you, set up your own fork. Yes it's a lot of work that will beget more work. But that's what important things usually entail.
Once you have your fork, you can set your own bar for contributions and other project policies.
To me, all this seems like a reasonable filter.
Not much of a barrier when if contributing to this particular code base was of high personal importance.
I mean, if that's the way the team works. That's the way it works and if it isn't the way a particular person wants to work then perhaps they are not a good fit with the team.
[This is not intended as snark] If the project is important to you and the team doesn't work in a way that works for you, set up your own fork. Yes it's a lot of work that will beget more work. But that's what important things usually entail.
Once you have your fork, you can set your own bar for contributions and other project policies.
Well I mean I started out essentially with my own fork, that has modifications that make sense to me. In doing so, I found a trivial optimization that it would be neat if it was backported.
Although this would benefit everyone using the mainline project, this is of very low personal importance to me and my patience for navigating an obstacle course is fairly low, even if this is to the detriment of the wider developer community.
Although this would benefit everyone using the mainline project, this is of very low personal importance to me and my patience for navigating an obstacle course is fairly low, even if this is to the detriment of the wider developer community.
The goal of the filter is probably to pass people for whom benefiting everyone who uses the project is important because in the long run that's more valuable to the team and more sustainable for the project.
I agree with you in general. But in this specific case, a walk by merge request should be acceptable. To anyone who is familiar with Java enought to be able to work on performance sensitive code, the described change is a no brainer. It doesn't need to be documented, it doesn't need to be discussed, I am pretty sure Intellij IDEA would highlight it as proposed change for performance reasons.
A lot of projects like this can / should be forked. It depends on how much credit you want, if someone then looks at your fork and incorporates the change into mainline themselves.
Well I don't want credit and I don't have the time to maintain a fork. I already have more than enough on my plate.
If you don't have time to make a fork where do you find time to complain or file bug reports with the upstream? The only person you have to maintain a fork for is you; you don't even have to submit a fix upstream. You don't even have to put it on GitHub.
I've got code (with stars!) on GitHub. It's not all the code I'm willing to give away; it's all the code I'm willing to honor some vague level of public commitment for curation.
There are a lot of shitty places to work. I worked at a place that told me I couldn't take the time to submit a bug report upstream because of "OpSec"! Utter baloney.
I've worked places where the upstream was religion: there are no bugs in the upstream, you're using it wrong.
I've worked places where only packages which come with some distro or package manager are allowed. (And these places always use the public repos. They also habitually complain about Docker fees.)
I understand, but I do not sympathize. If I have to choose between fixing your workplace and fixing software I use, which is it going to be?
I've got code (with stars!) on GitHub. It's not all the code I'm willing to give away; it's all the code I'm willing to honor some vague level of public commitment for curation.
There are a lot of shitty places to work. I worked at a place that told me I couldn't take the time to submit a bug report upstream because of "OpSec"! Utter baloney.
I've worked places where the upstream was religion: there are no bugs in the upstream, you're using it wrong.
I've worked places where only packages which come with some distro or package manager are allowed. (And these places always use the public repos. They also habitually complain about Docker fees.)
I understand, but I do not sympathize. If I have to choose between fixing your workplace and fixing software I use, which is it going to be?
In that sense of the word, I already have made a fork. But I think it would be useful if my patch helped other people's version of the code be faster too. A forked version of the code that alters 3 characters in one place and is never maintained does not help with that even a little bit.
Given a choice of the version of the code that maintained, and the version of the code where one function is much faster, but is abandoned, how many do you think will go looking for the latter?
Given a choice of the version of the code that maintained, and the version of the code where one function is much faster, but is abandoned, how many do you think will go looking for the latter?
You're not a stranger here. I looked through your submissions for one about the specific issue at hand, didn't see anything about OpenNLP. Even if it doesn't stay on page 1 for days a Show HN is a submission, and people can look for it in your submissions.
Things like that. It's an example of not helping them find it. Maybe you don't even need the code, or all the code. Maybe it's a common enough issue that a blog post or Show HN with _just that_ would be enough. Heck, a Twitter thread: less is more!
Things like that. It's an example of not helping them find it. Maybe you don't even need the code, or all the code. Maybe it's a common enough issue that a blog post or Show HN with _just that_ would be enough. Heck, a Twitter thread: less is more!
Well I'm not going to submit it to HN. I have no reason to expect the developers of OpenNLP to read HN. Overall I'm not going to promote a fork I have no desire or intention of maintaining. That would just be misleading people.
I don't want to be an OpenNLP developer.
I don't want to be an OpenNLP developer.
[deleted]
> Johnson closed the project to contributions in January 2021, explaining in a section of the README titled "Open-Source, not Open-Contribution" that dealing with even small code contributions was too time-consuming.
> "As the author of BoltDB, I found that accepting and maintaining third-party patches contributed to my burn out and eventual archival of the project," he wrote. "Even small contributions typically required hours of my time to properly test and validate them[...]"
I'm weirded out when I realize that I've run into someone where this needs to be explained.* The amount of ostensible "engineering" folks who are evidently afflicted with time-cost blindness or can't seem to grapple with the ideas behind basic comparative analyses of reward versus investment is staggeringly high.
* and, of course, this compounds the problem, because the explanation takes time, too...
> "As the author of BoltDB, I found that accepting and maintaining third-party patches contributed to my burn out and eventual archival of the project," he wrote. "Even small contributions typically required hours of my time to properly test and validate them[...]"
I'm weirded out when I realize that I've run into someone where this needs to be explained.* The amount of ostensible "engineering" folks who are evidently afflicted with time-cost blindness or can't seem to grapple with the ideas behind basic comparative analyses of reward versus investment is staggeringly high.
* and, of course, this compounds the problem, because the explanation takes time, too...
Complex projects need to have extensive tests if they are to accept contributions from everyone. I don't mean just unit tests - also extensive integration tests run with sanitizers and static analyzers as well. Without this kind of tests, you accept a significant probability of frequent bugs popping up (especially if you allow contributions from people unfamiliar with the code).
It's perfectly fine for authors to decide they don't want to follow this route and simply disallow most contributions (instead of investing into the test infrastructure required to enable them).
It's perfectly fine for authors to decide they don't want to follow this route and simply disallow most contributions (instead of investing into the test infrastructure required to enable them).
Yep. I have a strict policy of requiring unit tests to be added before I merge any new feature in a pull request. For small features, all the contributor needs to do is add a couple of test functions to the existing testing infrastructure, but I find it still drops the number of PRs by about 5x or something. It’s really remarkable. And I haven’t found a downside to this policy yet.
I have this too, but with a specification-by-example integration test with a brief explanation that autogenerates readable "step by step" markdown how-to docs.
The idea being that new features should be fully tested and clearly documented before being merged - ideally with a minimum of overhead. Because if you defer either, it likely won't get done.
The idea being that new features should be fully tested and clearly documented before being merged - ideally with a minimum of overhead. Because if you defer either, it likely won't get done.
At some size, a project grows beyond the scope of what one person can do.
Until then it’s possible that taking contributions is more work that the author doing it themselves.
In any case, extensive test coverage is a the only way I think you can take contributions for even a medium size project.
I have a o(10k) loc project that takes contributions. The contributions are more for community building than anything else. I evaluate pull requests based on code quality and if the tests pass - I don’t ever manually test it.
It’s a lot of work to do even just that when the project falls off my priority list.
Until then it’s possible that taking contributions is more work that the author doing it themselves.
In any case, extensive test coverage is a the only way I think you can take contributions for even a medium size project.
I have a o(10k) loc project that takes contributions. The contributions are more for community building than anything else. I evaluate pull requests based on code quality and if the tests pass - I don’t ever manually test it.
It’s a lot of work to do even just that when the project falls off my priority list.
It's not about testing only. All future features have to be vetted against the design decisions made in those contributions. Maybe the primary maintainer, after accepting a contribution, has to mind consistency with a feature, they now have to make Tain they don't care about from the start and is in the way for a feature they'd like.
Taking contributions has long-term cost.
Taking contributions has long-term cost.
I don't understand how this is supposed to be a response to what I wrote.
I was agreeing with you and expanding on what you said about reward vs investment.
I don't think people "need" this to be explained to them. By now we have had decades of "show us the code" and "pull requests welcomed" responses from free and open source software maintainers. Now that people are sending code, it's somehow detrimental to their mental health?
I respect their sincerity at least. It's better to know up front when the maintainer isn't actually interested in engaging with you. Nothing's worse than sending a patch in and not even getting a response.
I respect their sincerity at least. It's better to know up front when the maintainer isn't actually interested in engaging with you. Nothing's worse than sending a patch in and not even getting a response.
Projects that have the currently fashionable dogma that every contribution counts and must be considered degrade and lose the best contributors.
Either they are directly run by corporations, in which case they are just designed to "grow the team", or they are taken over by politicians who work for corporations and want to establish themselves as ruthless managers.
CPython falls in the latter category, which is why useless things keep being added and bugs creep in.
Either they are directly run by corporations, in which case they are just designed to "grow the team", or they are taken over by politicians who work for corporations and want to establish themselves as ruthless managers.
CPython falls in the latter category, which is why useless things keep being added and bugs creep in.
Hashicorp and Terraform are pretty notorious about rejecting/ignoring all community PRs. I once saw Hashicorp say that someone was allowed to come up with a proposal for a proposal for improvement, and that might get read but a real change would not even be considered.
Ctrl-F free - Phrase not found
What a coincidence.
I'm not a card carrying FSF member but that seems like a deliberate omission from the admittedly brief history. However also fairly off-topic as criticisms go.
A maintainer willing to reject contributions is a good sign to me - BDFL with a vision prevents mission creep and associated ills. The right to fork alleviates most of the negatives.
What a coincidence.
I'm not a card carrying FSF member but that seems like a deliberate omission from the admittedly brief history. However also fairly off-topic as criticisms go.
A maintainer willing to reject contributions is a good sign to me - BDFL with a vision prevents mission creep and associated ills. The right to fork alleviates most of the negatives.
This isn't about willingness to reject patches though. It's about maintainers who are not even open to receiving them.
I have to say, for the project mentioned, Litestream, which is licensed under Apache-2.0 license thus allows close-source redistribution, "Open-Source, not Open-Contribution" might not be the best combination for it. Because one can simply take the source code, make their own fork and never bother trying to back-contribute now that contribution is extremely hard if still possible at all. It's just not strategically smart.
Don't get me wrong, doing so still make sense for this specific case where the author has many important things going on in their life other than the project (I feel it, I don't even want to read email after duty time). But for project like this, maybe one of the GPL is better? Because with GPL, you force other people to open source their forks under the same license, this enables you to cherry-pick the fork you want back to the origin, at the time of your own choose.
Don't get me wrong, doing so still make sense for this specific case where the author has many important things going on in their life other than the project (I feel it, I don't even want to read email after duty time). But for project like this, maybe one of the GPL is better? Because with GPL, you force other people to open source their forks under the same license, this enables you to cherry-pick the fork you want back to the origin, at the time of your own choose.
You've completely missed the author's point. The code itself takes negligible time and effort to write himself. Accepting code from someone else takes more time and effort than it saves.
It works for sqlite (public domain though, not apache-2.0)
https://www.sqlite.org/copyright.html
https://www.sqlite.org/copyright.html
The reasoning is specific and pretty interesting IMO. Contributions are accepted as long as they stay public domain.
“In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain.”
I’d guess this compares to the GPL in interesting ways too (i.e., unlike GPL public domain code can be used/copied/distributed without license, even in proprietary settings and for profit, but attribution, credit & copyright must be waived first).
“In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain.”
I’d guess this compares to the GPL in interesting ways too (i.e., unlike GPL public domain code can be used/copied/distributed without license, even in proprietary settings and for profit, but attribution, credit & copyright must be waived first).
Wonder if this means they'll make it possible to disable the Pull Request tab.
There should still be an easily discoverable explanation why the project is not accepting contributions.
Genuine question, why? It's not like the project (at least by default) owes anybody any explanation why it's run the way it is or why contributions are not accepted.
The project owner could of course just write “No” without any explanation, but most projects I’ve seen that don’t take PRs have a reason for it: they prefer patches by mailing list, or don’t accept contributions but have a forum where you can post patches, or are a mirror of an upstream you should contribute to instead, or whatever. Usually this information is in the readme, or a wiki somewhere, or an automated PR-closing bot; but it would be a lot easier all round if GitHub let you replace the PR tab with some text so there was a consistent place to look for this information.
-Nobody- cares if your lonesome project is not accepting PR or even better stands denuded of any pretense of README, etc. For these it is sufficient to have a OSS license named and you’re good to go. And if you ignore PRs — and you are under no obligations to do this imho — no one will post to HN to tattle on you, because:
All these discussions are about ~hot properties. Implicit in all this is ego, prestige, and potential for profits, that is ownership, attribution, and control of some kind. You see the same dynamics apply at the next level of OSS projects hitting pay dirt ($) and locking horns with Cloud providers and ‘modifying’ OSS licenses.
All these discussions are about ~hot properties. Implicit in all this is ego, prestige, and potential for profits, that is ownership, attribution, and control of some kind. You see the same dynamics apply at the next level of OSS projects hitting pay dirt ($) and locking horns with Cloud providers and ‘modifying’ OSS licenses.
In the absence of such a thing, just assume the author is tired of being told "there should be..."
> accepting and maintaining third-party patches contributed to my burn out
When you have multiple collaborators you will have a management overhead. There's no way around it. You will need to have discussions among team members, co-ordination. It doesn't work by everybody just making their change-sets which are then (simply) pulled together. So the project owner needs to become a manager. And that is probably not what they want to become.
I can envision there could be a better way which would be not to accept random pull-requests but requesting pull-requests for specific changes with a set of unit-tests that must pass after those changes are made. Still the "manager" must write such change-requests and their validating unit-tests. This is all needed when you add multiple collaborators to the project. It might help the overall scale-up of the project but it does mean somebody has to take on the task of management.
When you have multiple collaborators you will have a management overhead. There's no way around it. You will need to have discussions among team members, co-ordination. It doesn't work by everybody just making their change-sets which are then (simply) pulled together. So the project owner needs to become a manager. And that is probably not what they want to become.
I can envision there could be a better way which would be not to accept random pull-requests but requesting pull-requests for specific changes with a set of unit-tests that must pass after those changes are made. Still the "manager" must write such change-requests and their validating unit-tests. This is all needed when you add multiple collaborators to the project. It might help the overall scale-up of the project but it does mean somebody has to take on the task of management.
Unpopular Opinion.
>> Johnson closed the project to contributions in January 2021, explaining in a section of the README titled "Open-Source, not Open-Contribution" that dealing with even small code contributions was too time-consuming.
Well according to comments on HN and Twitter from around 2016 - 2022. The rarely disputed ( Or disputed but downvoted ) definition of Open Sources means building a community around the project. If it doesn't accept outside contribution and the code doesn't give back and stays within the community ( ~GPL ) it is not true open source.
So I am glad How "open" could open source be is finally back on the table of discussions. But it is sad as it is often the case most people learn it the hard way.
>> Johnson closed the project to contributions in January 2021, explaining in a section of the README titled "Open-Source, not Open-Contribution" that dealing with even small code contributions was too time-consuming.
Well according to comments on HN and Twitter from around 2016 - 2022. The rarely disputed ( Or disputed but downvoted ) definition of Open Sources means building a community around the project. If it doesn't accept outside contribution and the code doesn't give back and stays within the community ( ~GPL ) it is not true open source.
So I am glad How "open" could open source be is finally back on the table of discussions. But it is sad as it is often the case most people learn it the hard way.
If the license for the code gives the users' community the right to fork (as with every legitimate FLOSS license) that's enough. Whether to accept outside countributions or not is simply a maintainership concern, that can be addressed by forking the project. For instance, the current GCC project is the outcome of what was originally a fork (Egcs) since the original GCC project was perceived as not being open to outside contributors.
open-source
/əʊp(ə)nˈsɔːs/
adjective
denoting software for which the original source code is made freely available and may be redistributed and modified
Adding community to this definition is a stretch.
It really doesn't matter if in practice communities form around projects, there are far more open source repositories on GitHub that have zero outside contributions, those projects are still open source.
Adding community to this definition is a stretch.
It really doesn't matter if in practice communities form around projects, there are far more open source repositories on GitHub that have zero outside contributions, those projects are still open source.
You could try that definition during the 16 - 22 time period and experience the backlash on HN and Twitter.
It is also interesting most of these zealotry were gone by the time Fed raises Interest rate and Tech companies started laying off or delaying bonuses.
It is also interesting most of these zealotry were gone by the time Fed raises Interest rate and Tech companies started laying off or delaying bonuses.
I stopped caring what those people think a decade ago.
Mine isn’t at all. I’ve cloned all the C/C++ open source projects; Linux kernel, some distros, productivity apps… and am using AI to normalize it into a code monolith and manage it as I go.
I have no intention to open source it because at this point in life I find the public has a credibility problem; we’re cruising right along indifferent about the mess we’re making for the future; why give a shit about the people around now if future peoples job is clean up our mess?
I have no intention to open source it because at this point in life I find the public has a credibility problem; we’re cruising right along indifferent about the mess we’re making for the future; why give a shit about the people around now if future peoples job is clean up our mess?
Open enough to be scraped and remixed by CoPilot, apparently
Bot accepting contributions is fine. It’s still Open Source Definition so anyone can fork it and accept contributions.
Always remember to s/GitHub/Microsoft/g
broken on Firefox mobile. Mirror: https://archive.is/0bxwR
The page works for me in Firefox on Android. What problem are you seeing?
Loads fine now. Previously, the mobile layout was zoomed out due to a few elements stretching the view port width.
There is also risk of someone taking project and undercutting your income. Like with Elastic and cloud.
I have opensource project under very liberal license, but never published build script and unit tests. Most people do not even notice, they just check license.
I have opensource project under very liberal license, but never published build script and unit tests. Most people do not even notice, they just check license.
Oracle does the same thing with MySQL to limit how much MariaDB can do.
> Open source eats the world (and needs some Tums)
> Early software was written by researchers and academics, and open by default—it couldn’t even be copyrighted until 1974. We didn’t even have the now-common phrase “open source” until Christine Peterson coined it in 1998. That same year, the OSI formed and established the aforementioned open source definition, which remains the yardstick by which openness is judged today.
I realise that this is intentionally a very highly-compressed version of history, but completely eliding the creation of the Free Software movement in the '80s, which Open Source grew out of (and specifically in reaction to), feels more like a bit of creative whitewashing than just a "well, we didn't have space to fit in everything" editing choice.
Or is that just me?