How ‘open’ should your open source be?
github.com
github.com
> 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?
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.
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.
"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.
Also, this is your readme so it’s not like you have some editor pressuring you to cut down.
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.
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 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.
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.
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?
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?
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!
I don't want to be an OpenNLP developer.
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.
> "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...
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).
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.
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.
Taking contributions has long-term cost.
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.
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.
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.
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.
“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).
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.
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.
>> 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.
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.
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 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 opensource project under very liberal license, but never published build script and unit tests. Most people do not even notice, they just check license.