8 ms·

How ‘open’ should your open source be?

• nailer 3y ago
  Bot accepting contributions is fine. It’s still Open Source Definition so anyone can fork it and accept contributions.
• evh 3y ago
  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.
  • matheusmoreira 3y ago
    This isn't about willingness to reject patches though. It's about maintainers who are not even open to receiving them.
• teddyh 3y ago
  Always remember to s/GitHub/Microsoft/g
• reillyduncN 3y 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?
• galaxyLogic 3y ago
  > 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.
• ignoramous 3y ago
  broken on Firefox mobile. Mirror: https://archive.is/0bxwR https://archive.is/0bxwR
  • cpeterso 3y ago
    The page works for me in Firefox on Android. What problem are you seeing?
    • ignoramous 3y ago
      Loads fine now. Previously, the mobile layout was zoomed out due to a few elements stretching the view port width.
• mkj 3y ago
  Wonder if this means they'll make it possible to disable the Pull Request tab.
  • vaylian 3y ago
    There should still be an easily discoverable explanation why the project is not accepting contributions.
    • mannykannot 3y ago
      In the absence of such a thing, just assume the author is tired of being told "there should be..."
    • jzm2k 3y ago
      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.
      • wolfgang42 3y ago
        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.
      • eternalban 3y ago
        -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.
• marginalia_nu 3y ago
  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.
  • m3047 3y ago
    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.
    • marginalia_nu 3y ago
      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.
      • m3047 3y ago
        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?
• nirui 3y ago
  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.
  • stock_toaster 3y ago
    It works for sqlite (public domain though, not apache-2.0) https://www.sqlite.org/copyright.html https://www.sqlite.org/copyright.html
    • dahart 3y ago
      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).
  • nunuvit 3y ago
    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.
• cxr 3y ago
  > 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...
  • Plasmoid 3y ago
    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.
  • FartyMcFarter 3y ago
    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).
    • johannes1234321 3y ago
      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.
• ksec 3y ago
  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.
  • onlypositive 3y ago
    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.
    • ksec 3y ago
      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.
      • onlypositive 3y ago
        I stopped caring what those people think a decade ago.
  • zozbot234 3y ago
    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.
• Throw73849 3y ago
  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.
  • Plasmoid 3y ago
    Oracle does the same thing with MySQL to limit how much MariaDB can do.
• Karellen 3y ago
  > First, let’s take a look at how we got here. > 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?
  • forgotmypw17 3y ago
    It's not just you. I think it is with great generosity that this article can be described as merely ignorant.
  • rwwmike 3y ago
    > 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.
    • dancemethis 3y ago
      Honestly, it is not possible to perceive it as being written in good faith.
    • Karellen 3y ago
      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.
      • rwwmike 3y ago
• EGreg 3y ago
  Open enough to be scraped and remixed by CoPilot, apparently