11 ms·

Open Source and Saying “No”

187 points by bo0tzz 4y ago

deleted 4y ago
[deleted]
slbtty 4y ago
Doing exactly the opposite is also a right approach: Absorb as many features as possible, so that more people will be gravitated into a centralized place. For bugs, if the original feature submitter isn't around, potential new maintainers will emerge and fix them.
- archerx 4y ago
  That’s very idealistic and unfortunately life is far from ideal. Its better to do one thing very well than to do many things badly.
- twawaaay 4y ago
  This only works for few high profile projects. Most projects developed this way die of development resources starvation. Once you have added all those features you will face all the consequences of developing a complex system -- difficulty to get anything done, new devs requiring substantial amount of time to get started, people getting discouraged quickly, etc. As you add complexity, the ways users use your platform will grow exponentially -- potentially causing an explosion of bugs. I don't mean users using your platform in many different ways is bad, the question is "Can you support it?" If you run into developer resource starvation users will find that you are making no progress and will find an alternative and this will make your project even less enticing for contributors. This is how a project dies. If you are single developer and want to do something useful for community your best shot is to make something simple and add things judiciously. So how do large open source projects survive and how are they different? The issue is that when it comes to contributors, relatively few large projects receive most of the contributions. Everybody wants to contribute to something well known, high profile, used by a lot of people. Not many developers want to make it their mission to support a useful but an obscure plugin to something else.
- gchadwick 4y ago
  I'd say precedent is against you here. There's many examples of widely used open source projects that don't get lots of free maintenance effort. Maintaining something well is hard and requires commitment, you can't just crowd source it with people dipping in and out with the occasional fix and new feature. Being careful about what PRs you accept, especially when it's a big new feature is crucial to the health of an open source project and the mental health of its maintainers.
- deleted 4y ago
  [deleted]
- rickdeckard 4y ago
  >Projects should do exactly the opposite: This may work as a strategy for a VC-backed startup, where you just throw money into resources to create the largest possible gravity for your product, and solve the technical debt by growing your team once you have a critical (paying) userbase. But how would this work when there's no money to throw around, your product is free and every contributor is actually a volunteer who still needs to earn his living elsewhere?
- bayindirh 4y ago
  Making this will exponentially increase the glue code required to tie everything together. So, while new developers fix the features, they'll also need to fix that glue layer too, making the work twice or thrice as big. Also things will also even get more complicated as long as things get added into the mix. This is why UNIX philosophy is very important. Keeps software simple, compact and much more easier to maintain.
  - ilyt 4y ago
    It can work but you have to have a vision on how to integrate extra features, not just shove them into the codebase. Consistent plugin API allowing to plug-in code in various parts of the app takes a bunch of effort but now you're magically separated by a wall of code from the contributors, as you're never a blocker for someone's else effort to add features, and the stuff you don't want to maintain can land in contrib repo
- deafpolygon 4y ago
  Interop is better. Keep things focused and simple, and focus on interop between tools.
- badsectoracula 4y ago
  For all the negative responses you get, there are a bunch of open source projects that work kinda like this. Lazarus, and to a lesser extent Free Pascal, are basically like that. New features are added often and bug fixes to code written by others who aren't around (or don't have time) are submitted all the time (e.g. personally i'm more of a user than a developer of the project but i always use the git version built from source so that i can quickly fix any bugs that annoy me). The codebase is also far from small and the project is an IDE that tries to do "everything", so far from "doing one thing". Lazarus has been around for at least a couple of decades, so i think that shows projects do not necessarily die when doing that. It might have to do with not having some big company push their weight around so it is largely community developed and driven. Also it is by far the most popular IDE for the language it is written on, so perhaps it is easier to find contributors.
- acdha 4y ago
  The other factor to consider is how features complicate unrelated maintenance and new development. If you accept new features which are affect other parts of the codebase, you might find that the things you are finding volunteers to work are made harder due to something most people don’t use and thus aren’t jumping to spend time supporting. Years back I worked on a search engine abstraction library for Django. I’m not sure the concept is affordable at all - search engines are less alike than SQL databases — but one thing we constantly had problems with was that most volunteers only needed one backend but any new abstraction would need to be implemented for at least 3.
- Cthulhu_ 4y ago
  What you're describing is (imo) more a framework than a library, then; think Angular, which comes with loads of modules attached or standardized.
- ilyt 4y ago
  Kinda depends on project. Accepting features willy nilly can make a mess both ou of codebase and project direction.
gchamonlive 4y ago
I maintain python sysrsync package and my idea at first was to validate files before syncing with systems rsync. That was rightly pointed out by users as bloat and I took it off in a major release. Similarly there is a feature request that although justified for the sake of symmetry (I support exclude in the API but not include) I am reluctant to add it because I really don't want it to have more features, when there is a way to access all rsync flags using options argument.
blitzar 4y ago
I know it is fantasy land, but a healthy fork -> reintegrate way down the line cycle would benefit all parties. However, humans being humans egos etc get in the way.
- zozbot234 4y ago
  You can just fork and then ask for your changes to be pulled into their own tree.
  - a99c43f2d565504 4y ago
    That's called contributing via a pull request isn't it?
  - blitzar 4y ago
    But my fork is better than yours because it has the feature I wanted and you rejected ... So maybe you should be integrating your work into my project.
- lliamander 4y ago
  Which is tragically amusing, since arguably the main reason why the source was made available in the first place was to support forking.
  - blitzar 4y ago
    Open source software is simultaneously in great health and badly badly broken at the same time.
kreco 4y ago
The main issue mentioned in the article is to use Github. The "issues" on Github could be "bugs", "feature request" or even "improvement" (it could be anything actually). If I were to maintain a project by myself I would rather just deal with bugs or performance issue, and allow feature request in a separated queue where people can upvote it and discuss. The feature request queue could sit there forever as it's just a view of what people wants and not how the project should go. Also react-native-fs mentioned in the article only have 4 bugs opened. The rest is just noise and unlabelled issues. Note that there might be a considerable amount of bugs in those unlabelled issues. As a maintainer I should not spend my time to label anything, either you enter it as bug and I'm considering it since bug are supposed to be critical, either it's not and it's going into a sperate queue I can read whenever I have more free time.
- Kovah 4y ago
  Github isn't really the issue here, because it offers the tools to make this differentiation. Maintainers just have to use it. At Github, you can use issue templates that have a set of pre-defined questions and add labels to the created issues. Example from my own project: https://github.com/Kovah/LinkAce/tree/main/.github/ISSUE_TEMPLATE https://github.com/Kovah/LinkAce/tree/main/.github/ISSUE_TEM... Users can only create bugs and have to answer some detailed questions, because I really don't want to deal with "XYZ is not working"-types of issues without any context or further information. Feature requests are redirected to the discussion forums first. It works very well for me.
  - RobotToaster 4y ago
    >Github isn't really the issue here >requests are redirected to the discussion forums first The fact you're having to hack the forum into a feature request tracker seems like an issue with github?
    - nightpool 4y ago
      The forum was built to be a feature request tracker. It's used extensively for that purpose at Github (see e.g. https://github.com/orgs/community/discussions/categories/codespaces https://github.com/orgs/community/discussions/categories/cod...). It's the main usecase for the forum (with a secondary use-case being stack-overflow-like q&a). I don't think anybody is hacking anything
robertlagrant 4y ago
Low dependency analysis is one of the reasons I like Flask[0]. [0] https://github.com/pallets/flask/blob/main/setup.py https://github.com/pallets/flask/blob/main/setup.py
- orf 4y ago
  Weird, I dislike Flask because it quickly becomes a dependency soup the moment you want to add something simple like forms or a DB. Django has less dependencies[1] - one "real" one (asgiref), one to work around a sqlite issue ("sqlparse"), and up to two timezone related backports depending on your OS (tzcata, zoneinfo). Plus obviously a library for your db backend, if you're not using sqlite. And with that you get a lot more for less, compared to a Flask + wtforms + sqlalchemy + alembic "starter setup": > $ pip install flask "sqlalchemy[postgres]" wtforms alembic > $ pip freeze | wc -l > 13 > $ pip install django psycopg2-binary > $ pip freeze | wc -l > 4 1. https://github.com/django/django/blob/60a7bd89860e504c0c33b02c78edcac87f6d1b5a/setup.cfg#L42-L45 https://github.com/django/django/blob/60a7bd89860e504c0c33b0...
  - acdha 4y ago
    Ditto. I liked Flask years ago but unless you’re doing very contained microservices it always ends up feeling like you’re building your own framework. This isn’t a slam on Flask but rather, I think, a reminder that we’re so prone to think about the fun of being able to customize everything without thinking about the maintenance trade-offs.
  - robertlagrant 4y ago
    Django is also excellent for this. This isn't a two-horse race :)
  - Octabrain 4y ago
    I understand what you say and the appeal for it. However, I have to admit that one of the reasons I like Golang over Python (Although I develop in both frequently and enjoy them) is because of the language mentality of libraries over frameworks. I prefer many explicit different dependencies glued together from one's own logic than a batteries included Framework where big part of the magic happens under the hood and ways of doing things must follow an specific path that does not always applies for your specific business case. I think this approach gives a better flexibility (and can cause annoying paralysis by decision too).
nuc1e0n 4y ago
"All in all I'm being much more careful when researching dependencies and libraries before bringing them in." - As everyone should be. Folks are too blasé about importing bloated dependancies.
- ilyt 4y ago
  It's pretty easy to end up with one even if you tried to pick some popular and supported library, as they might not be a discerning as you in their dependencies
dncornholio 4y ago
Life is too short to care about non issues. If (part) of a package solves your problem, just use that part. I don't see how an opinion of the package features stops you from solving your problem :)
- acdha 4y ago
  This works best if you don’t care about security and aren’t planning to stick around at the same job. If that’s not the case, there is a real cost to a regular stream of updates required for features you don’t use - especially when there’s some kind of major upgrade like Node has had a couple of times which forces everything to update, and you get some period where not all of those dependencies have shipped updates or backwards-incompatible changes are required, and you might have to help get changes made upstream or fork something. Better hope no security exploits are found when you’re in the middle of that process…
  - ilyt 4y ago
    That's probably bad example because if you decided that node is a security problem you're fucked as you'd have to change the language you use...
    - acdha 4y ago
      I wasn't saying that Node itself is a security problem but rather that the community is biased towards rapid upgrades, trading long-term API stability for the ability to use new things quickly. That's a valid trade-off which a lot of people have enjoyed but it does mean that you need to think about whether you have the resources to keep surfing that wave when adding new dependencies. It does seem like the community is reconsidering that balance, too, after years of things like leftpad or worse have been highlighting how exposed most projects are to a single compromised maintainer.
      - dncornholio 4y ago
        I'm not saying you should blindly install the first package you find. My point is, when a program works, and it's maintainable, there's no problem. So many message here are saying what could go wrong, but I have NEVER actually run into the issues people seem to imply. In my opinion, your 'community' is just people who shout hard but hardly do any coding IMHO.
jacooper 4y ago
But saying No too much might result in features sorely missing from your Project. For example, Mastodon quote tweets, or viewing accounts follows and followers.
- rapnie 4y ago
  "Sorely missing" really depends.. for you, a particular user, maybe. But e.g. not having quote tweets in Mastodon was a very deliberate decision (I don't have the issue at hand) not to go in the direction of Twitter here. Quote tweets have their downsides too. This was about keeping project direction and doing things the Mastodon way.
  - jacooper 4y ago
    Maybe not quote tweets. But backfilling old content, full followers and follows? These are indeed sorely missing. Let alone the horrible Mastodon search.
asim 4y ago
Feature creep in open source is almost always because of user pressure "add this or I'm going elsewhere". Nobody has the insight to build in a modular way on top of that library or system, ironically despite being programmers! Sigh. Yet. The things that truly succeed find a way to evolve, scale and grow by learning to include contributors in a way that make them owners of their new contribution and more. It does not always happen. Not all projects can achieve the scale and funding to do it properly but those are the ones that succeed. Point to the ones that worked and there's the thousands of others that didn't, leaving the maintainers totally burned out. Turns out we're not born managers or project leaders. GitHub and others could do more to improve life for maintainers and users alike. I see sponsorships, but I don't see bounties! Where's the bounty programs? Reward the user for their contribution, reward the maintainer for their long term efforts. The platform needs to do more. Can't put all the pressure on the people using the platforms.
- manfre 4y ago
  > Nobody has the insight to build in a modular way on top of that library or system Sometimes it's less to due with lack of ability and more to do with wanting some one else to pay the cost.
  - geerlingguy 4y ago
    And often there is already a modular system ready, but the person requesting a feature is either too lazy or doesn't know the system enough to use it (or sometimes even know it exists). This seems especially true for drive-by requests where someone on a dev team has a feature they are required to implement in XYZcorp's application. They don't know the platform well, they see the feature isn't provided out of the box, so instead of doing much research, they just hop in the issue queue and request it.
    - cestith 4y ago
      Sometimes the modular system is very flexible and straightforward. Other times the system really is modular, but makes many assumptions which make little sense to and are even difficult to foresee by someone less familiar with the overall system. See all the years of discussion over libraries vs frameworks vs complete code ecosystems. If I have a three week deadline and it takes three months to come up to speed with your system's docs and code, I'm going to ask for something without an up-front PR before I take it on myself.
wpietri 4y ago
It seems like there's an implicit theory here: if one maintainer says no, then some other competent maintainer will pop up to handle the excluded bit of functionality in a separate library. Why would that be the case? And what about the alternative of getting that person to participate in expanding the existing project?
a_c 4y ago
Imo more projects should start paying its author to prioritize their "issues", feature or bug
- TylerE 4y ago
  Isn't that literally Peter robbing Peter to pay Peter for 99%+ of projects? Where is this pay coming from?
- hgs3 4y ago
  I'm planning to use this model when I eventually launch my company. What's unfortunate is I need to handle payments myself because GitHub doesn't have a payments feature for maintainers to leverage.
fullstackchris 4y ago
Ah, the author has found the infamous (in my opinion, much much worse than average) state of React Native packages and libraries. For some reason it seems especially React Native packages have a horrible bug rate, low maintenance frequency, and worse... (as an example of what I've seen more than once now, critical bugs are introduced in between minor version changes!) Perhaps it's the ecosystem itself (needing to have native code AND javascript code for BOTH iOS and Android), or the pace of React Native changes itself, but I'm not sure. Anyway, wholeheartedly agree with the author that one should audit and research packages very carefully before deciding to add them to your codebase. And in React Native, small, "do one thing and do it right" packages would be an unbelievable breath of fresh air.
- TheRealPomax 4y ago
  It's almost as if not getting paid for the work confers zero reasons to fix bugs that don't affect the package author(s) themselves? Weird how that seems to be the case, if only there was some way that people who made money off open source could help get issues fixed by, I don't know, offering something in return? (React-Native's ecosystem isn't even remotely worse than average, you're just looking at it in absolute terms: the more popular a framework is, the more people will create tooling around it, and so the more stale projects you run into. If you rely on packages not going stale, and your company literally makes money thanks to them, be that directly or by helping you put out your name so you can make those dollars, have an open source budget, and use it)
avg_dev 4y ago
i believe that software design is really hard. it seems appropriate to mention "conceptual integrity" which is a term i believe was coined by the (recently) late great fred brooks. his book "the design of design" talks about it a lot and i really found the discussion helpful. here is a very brief summary from his earlier book: https://en.wikipedia.org/wiki/The_Mythical_Man-Month#Conceptual_integrity https://en.wikipedia.org/wiki/The_Mythical_Man-Month#Concept... sometimes saying no is the right thing to do. as an aside, i find it a little distasteful that the author of this blog post chose to call projects out by name. these people are putting their efforts out for free and they are, to my eyes, taking flak for doing so.
that_guy_iain 4y ago
I say this nearly every time something like this is posted. The isn't isn't so much open source, it's that no one is getting paid. We're constantly relying on projects that we get for free where in esscence we're relying on goodwill. So much so, that people say don't add new features because you're depending on the goodwill of that contributor and they may disappear. Which is basically the same was the open source maintainer may disappear. Basically, this blog posts highlights why we should be paying for software libraries we use. All the downsides of proprietary code happens in open source. Open source projects don't add features you need, they can release a new version that has breaking changes and stop supporting the old version, they can just disappear, etc. However, the reality is, very rarely does popular proprietary just stop getting updated. While that happens in most somewhat popular open-source libraries. You can go to most mature open-source libraries and you'll see that the commit activity is down from when the project started. Many will say that's because it's feature complete. However, if you look at the open issues you'll see lots of activity. Often the issue is that the original maintainer has lost interest, be it because life - love affairs, children, sickness, etc, or that they've got a new hobby - arts, music, new tech, etc. I don't blame these maintainers, it's free and they owe me nothing. But at the same time I blame the industry for making it so common to build on these libraries that literally promise nothing for production code that you'll be extremely hard press to find a job that doesn't require you to build on top of FOSS. My prefered approach which I'm taking with my SaaS Boilerplate/General functionality bundle is use source-available license. Namely BSL - Business Source License with an additional grant that if you make less than $5k per month you don't need to pay. This allows the best of both worlds in my opinion. The ability to test it out, see it, use it for free in certain scenarios while making people who make money from it pay for it's maintenance. The full details of this license and approach can be read in the FAQ https://github.com/getparthenon/parthenon#faq https://github.com/getparthenon/parthenon#faq
- dec0dedab0de 4y ago
  The problem with paid proprietary code is that it almost inevitably devolves into a bloated mess of haphazard features being tacked on year after year by contractors who don't care about how hard it is to maintain, and don't even care if it works well because they don't need the code themselves, and the people buying the code don't use it, because they're buying it on behalf of a company and the people who actually use it just have to suffer through it. I think the one thing that would help open source more than anything else is if we outlawed contracts where the employer owns all copywritable material created by the employee.
sghosh2 4y ago
I wonder if having some sort of dependency scanner giving more upfront visibility would help clear things up. Then you'd be able to get a sense of what the composition of issues might look like. Seems like there's so many scanners out there that something must solve this.
Vanit 4y ago
Basically the same lesson can applied for saying no to feature requests from clients on your SaaS product; saying yes commits you to ongoing support, and you need to consider if it's worth it, particularly consider if said client is trying to outsource what should be bespoke work on their side, to you.

187 points by bo0tzz 4y ago

deleted 4y ago

[deleted]

Doing exactly the opposite is also a right approach: Absorb as many features as possible, so that more people will be gravitated into a centralized place. For bugs, if the original feature submitter isn't around, potential new maintainers will emerge and fix them.

archerx 4y ago
That’s very idealistic and unfortunately life is far from ideal. Its better to do one thing very well than to do many things badly.
twawaaay 4y ago
This only works for few high profile projects. Most projects developed this way die of development resources starvation. Once you have added all those features you will face all the consequences of developing a complex system -- difficulty to get anything done, new devs requiring substantial amount of time to get started, people getting discouraged quickly, etc. As you add complexity, the ways users use your platform will grow exponentially -- potentially causing an explosion of bugs. I don't mean users using your platform in many different ways is bad, the question is "Can you support it?" If you run into developer resource starvation users will find that you are making no progress and will find an alternative and this will make your project even less enticing for contributors. This is how a project dies. If you are single developer and want to do something useful for community your best shot is to make something simple and add things judiciously. So how do large open source projects survive and how are they different? The issue is that when it comes to contributors, relatively few large projects receive most of the contributions. Everybody wants to contribute to something well known, high profile, used by a lot of people. Not many developers want to make it their mission to support a useful but an obscure plugin to something else.
gchadwick 4y ago
I'd say precedent is against you here. There's many examples of widely used open source projects that don't get lots of free maintenance effort. Maintaining something well is hard and requires commitment, you can't just crowd source it with people dipping in and out with the occasional fix and new feature. Being careful about what PRs you accept, especially when it's a big new feature is crucial to the health of an open source project and the mental health of its maintainers.
deleted 4y ago
[deleted]
rickdeckard 4y ago
>Projects should do exactly the opposite: This may work as a strategy for a VC-backed startup, where you just throw money into resources to create the largest possible gravity for your product, and solve the technical debt by growing your team once you have a critical (paying) userbase. But how would this work when there's no money to throw around, your product is free and every contributor is actually a volunteer who still needs to earn his living elsewhere?
bayindirh 4y ago
Making this will exponentially increase the glue code required to tie everything together. So, while new developers fix the features, they'll also need to fix that glue layer too, making the work twice or thrice as big. Also things will also even get more complicated as long as things get added into the mix. This is why UNIX philosophy is very important. Keeps software simple, compact and much more easier to maintain.
- ilyt 4y ago
  It can work but you have to have a vision on how to integrate extra features, not just shove them into the codebase. Consistent plugin API allowing to plug-in code in various parts of the app takes a bunch of effort but now you're magically separated by a wall of code from the contributors, as you're never a blocker for someone's else effort to add features, and the stuff you don't want to maintain can land in contrib repo
deafpolygon 4y ago
Interop is better. Keep things focused and simple, and focus on interop between tools.
badsectoracula 4y ago
For all the negative responses you get, there are a bunch of open source projects that work kinda like this. Lazarus, and to a lesser extent Free Pascal, are basically like that. New features are added often and bug fixes to code written by others who aren't around (or don't have time) are submitted all the time (e.g. personally i'm more of a user than a developer of the project but i always use the git version built from source so that i can quickly fix any bugs that annoy me). The codebase is also far from small and the project is an IDE that tries to do "everything", so far from "doing one thing". Lazarus has been around for at least a couple of decades, so i think that shows projects do not necessarily die when doing that. It might have to do with not having some big company push their weight around so it is largely community developed and driven. Also it is by far the most popular IDE for the language it is written on, so perhaps it is easier to find contributors.
acdha 4y ago
The other factor to consider is how features complicate unrelated maintenance and new development. If you accept new features which are affect other parts of the codebase, you might find that the things you are finding volunteers to work are made harder due to something most people don’t use and thus aren’t jumping to spend time supporting. Years back I worked on a search engine abstraction library for Django. I’m not sure the concept is affordable at all - search engines are less alike than SQL databases — but one thing we constantly had problems with was that most volunteers only needed one backend but any new abstraction would need to be implemented for at least 3.
Cthulhu_ 4y ago
What you're describing is (imo) more a framework than a library, then; think Angular, which comes with loads of modules attached or standardized.
ilyt 4y ago
Kinda depends on project. Accepting features willy nilly can make a mess both ou of codebase and project direction.

gchamonlive 4y ago

I maintain python sysrsync package and my idea at first was to validate files before syncing with systems rsync. That was rightly pointed out by users as bloat and I took it off in a major release. Similarly there is a feature request that although justified for the sake of symmetry (I support exclude in the API but not include) I am reluctant to add it because I really don't want it to have more features, when there is a way to access all rsync flags using options argument.

blitzar 4y ago

I know it is fantasy land, but a healthy fork -> reintegrate way down the line cycle would benefit all parties. However, humans being humans egos etc get in the way.

zozbot234 4y ago
You can just fork and then ask for your changes to be pulled into their own tree.
- a99c43f2d565504 4y ago
  That's called contributing via a pull request isn't it?
- blitzar 4y ago
  But my fork is better than yours because it has the feature I wanted and you rejected ... So maybe you should be integrating your work into my project.
lliamander 4y ago
Which is tragically amusing, since arguably the main reason why the source was made available in the first place was to support forking.
- blitzar 4y ago
  Open source software is simultaneously in great health and badly badly broken at the same time.

kreco 4y ago

The main issue mentioned in the article is to use Github. The "issues" on Github could be "bugs", "feature request" or even "improvement" (it could be anything actually). If I were to maintain a project by myself I would rather just deal with bugs or performance issue, and allow feature request in a separated queue where people can upvote it and discuss. The feature request queue could sit there forever as it's just a view of what people wants and not how the project should go. Also react-native-fs mentioned in the article only have 4 bugs opened. The rest is just noise and unlabelled issues. Note that there might be a considerable amount of bugs in those unlabelled issues. As a maintainer I should not spend my time to label anything, either you enter it as bug and I'm considering it since bug are supposed to be critical, either it's not and it's going into a sperate queue I can read whenever I have more free time.

Kovah 4y ago
Github isn't really the issue here, because it offers the tools to make this differentiation. Maintainers just have to use it. At Github, you can use issue templates that have a set of pre-defined questions and add labels to the created issues. Example from my own project: https://github.com/Kovah/LinkAce/tree/main/.github/ISSUE_TEMPLATE https://github.com/Kovah/LinkAce/tree/main/.github/ISSUE_TEM... Users can only create bugs and have to answer some detailed questions, because I really don't want to deal with "XYZ is not working"-types of issues without any context or further information. Feature requests are redirected to the discussion forums first. It works very well for me.
- RobotToaster 4y ago
  >Github isn't really the issue here >requests are redirected to the discussion forums first The fact you're having to hack the forum into a feature request tracker seems like an issue with github?
  - nightpool 4y ago
    The forum was built to be a feature request tracker. It's used extensively for that purpose at Github (see e.g. https://github.com/orgs/community/discussions/categories/codespaces https://github.com/orgs/community/discussions/categories/cod...). It's the main usecase for the forum (with a secondary use-case being stack-overflow-like q&a). I don't think anybody is hacking anything

robertlagrant 4y ago

Low dependency analysis is one of the reasons I like Flask[0]. [0] https://github.com/pallets/flask/blob/main/setup.py https://github.com/pallets/flask/blob/main/setup.py

orf 4y ago
Weird, I dislike Flask because it quickly becomes a dependency soup the moment you want to add something simple like forms or a DB. Django has less dependencies[1] - one "real" one (asgiref), one to work around a sqlite issue ("sqlparse"), and up to two timezone related backports depending on your OS (tzcata, zoneinfo). Plus obviously a library for your db backend, if you're not using sqlite. And with that you get a lot more for less, compared to a Flask + wtforms + sqlalchemy + alembic "starter setup": > $ pip install flask "sqlalchemy[postgres]" wtforms alembic > $ pip freeze | wc -l > 13 > $ pip install django psycopg2-binary > $ pip freeze | wc -l > 4 1. https://github.com/django/django/blob/60a7bd89860e504c0c33b02c78edcac87f6d1b5a/setup.cfg#L42-L45 https://github.com/django/django/blob/60a7bd89860e504c0c33b0...
- acdha 4y ago
  Ditto. I liked Flask years ago but unless you’re doing very contained microservices it always ends up feeling like you’re building your own framework. This isn’t a slam on Flask but rather, I think, a reminder that we’re so prone to think about the fun of being able to customize everything without thinking about the maintenance trade-offs.
- robertlagrant 4y ago
  Django is also excellent for this. This isn't a two-horse race :)
- Octabrain 4y ago
  I understand what you say and the appeal for it. However, I have to admit that one of the reasons I like Golang over Python (Although I develop in both frequently and enjoy them) is because of the language mentality of libraries over frameworks. I prefer many explicit different dependencies glued together from one's own logic than a batteries included Framework where big part of the magic happens under the hood and ways of doing things must follow an specific path that does not always applies for your specific business case. I think this approach gives a better flexibility (and can cause annoying paralysis by decision too).

nuc1e0n 4y ago

"All in all I'm being much more careful when researching dependencies and libraries before bringing them in." - As everyone should be. Folks are too blasé about importing bloated dependancies.

ilyt 4y ago
It's pretty easy to end up with one even if you tried to pick some popular and supported library, as they might not be a discerning as you in their dependencies

dncornholio 4y ago

Life is too short to care about non issues. If (part) of a package solves your problem, just use that part. I don't see how an opinion of the package features stops you from solving your problem :)

acdha 4y ago
This works best if you don’t care about security and aren’t planning to stick around at the same job. If that’s not the case, there is a real cost to a regular stream of updates required for features you don’t use - especially when there’s some kind of major upgrade like Node has had a couple of times which forces everything to update, and you get some period where not all of those dependencies have shipped updates or backwards-incompatible changes are required, and you might have to help get changes made upstream or fork something. Better hope no security exploits are found when you’re in the middle of that process…
- ilyt 4y ago
  That's probably bad example because if you decided that node is a security problem you're fucked as you'd have to change the language you use...
  - acdha 4y ago
    I wasn't saying that Node itself is a security problem but rather that the community is biased towards rapid upgrades, trading long-term API stability for the ability to use new things quickly. That's a valid trade-off which a lot of people have enjoyed but it does mean that you need to think about whether you have the resources to keep surfing that wave when adding new dependencies. It does seem like the community is reconsidering that balance, too, after years of things like leftpad or worse have been highlighting how exposed most projects are to a single compromised maintainer.
    - dncornholio 4y ago
      I'm not saying you should blindly install the first package you find. My point is, when a program works, and it's maintainable, there's no problem. So many message here are saying what could go wrong, but I have NEVER actually run into the issues people seem to imply. In my opinion, your 'community' is just people who shout hard but hardly do any coding IMHO.

jacooper 4y ago

But saying No too much might result in features sorely missing from your Project. For example, Mastodon quote tweets, or viewing accounts follows and followers.

rapnie 4y ago
"Sorely missing" really depends.. for you, a particular user, maybe. But e.g. not having quote tweets in Mastodon was a very deliberate decision (I don't have the issue at hand) not to go in the direction of Twitter here. Quote tweets have their downsides too. This was about keeping project direction and doing things the Mastodon way.
- jacooper 4y ago
  Maybe not quote tweets. But backfilling old content, full followers and follows? These are indeed sorely missing. Let alone the horrible Mastodon search.

asim 4y ago

Feature creep in open source is almost always because of user pressure "add this or I'm going elsewhere". Nobody has the insight to build in a modular way on top of that library or system, ironically despite being programmers! Sigh. Yet. The things that truly succeed find a way to evolve, scale and grow by learning to include contributors in a way that make them owners of their new contribution and more. It does not always happen. Not all projects can achieve the scale and funding to do it properly but those are the ones that succeed. Point to the ones that worked and there's the thousands of others that didn't, leaving the maintainers totally burned out. Turns out we're not born managers or project leaders. GitHub and others could do more to improve life for maintainers and users alike. I see sponsorships, but I don't see bounties! Where's the bounty programs? Reward the user for their contribution, reward the maintainer for their long term efforts. The platform needs to do more. Can't put all the pressure on the people using the platforms.

manfre 4y ago
> Nobody has the insight to build in a modular way on top of that library or system Sometimes it's less to due with lack of ability and more to do with wanting some one else to pay the cost.
- geerlingguy 4y ago
  And often there is already a modular system ready, but the person requesting a feature is either too lazy or doesn't know the system enough to use it (or sometimes even know it exists). This seems especially true for drive-by requests where someone on a dev team has a feature they are required to implement in XYZcorp's application. They don't know the platform well, they see the feature isn't provided out of the box, so instead of doing much research, they just hop in the issue queue and request it.
  - cestith 4y ago
    Sometimes the modular system is very flexible and straightforward. Other times the system really is modular, but makes many assumptions which make little sense to and are even difficult to foresee by someone less familiar with the overall system. See all the years of discussion over libraries vs frameworks vs complete code ecosystems. If I have a three week deadline and it takes three months to come up to speed with your system's docs and code, I'm going to ask for something without an up-front PR before I take it on myself.

wpietri 4y ago

It seems like there's an implicit theory here: if one maintainer says no, then some other competent maintainer will pop up to handle the excluded bit of functionality in a separate library. Why would that be the case? And what about the alternative of getting that person to participate in expanding the existing project?

a_c 4y ago

Imo more projects should start paying its author to prioritize their "issues", feature or bug

TylerE 4y ago
Isn't that literally Peter robbing Peter to pay Peter for 99%+ of projects? Where is this pay coming from?
hgs3 4y ago
I'm planning to use this model when I eventually launch my company. What's unfortunate is I need to handle payments myself because GitHub doesn't have a payments feature for maintainers to leverage.

fullstackchris 4y ago

Ah, the author has found the infamous (in my opinion, much much worse than average) state of React Native packages and libraries. For some reason it seems especially React Native packages have a horrible bug rate, low maintenance frequency, and worse... (as an example of what I've seen more than once now, critical bugs are introduced in between minor version changes!) Perhaps it's the ecosystem itself (needing to have native code AND javascript code for BOTH iOS and Android), or the pace of React Native changes itself, but I'm not sure. Anyway, wholeheartedly agree with the author that one should audit and research packages very carefully before deciding to add them to your codebase. And in React Native, small, "do one thing and do it right" packages would be an unbelievable breath of fresh air.

TheRealPomax 4y ago
It's almost as if not getting paid for the work confers zero reasons to fix bugs that don't affect the package author(s) themselves? Weird how that seems to be the case, if only there was some way that people who made money off open source could help get issues fixed by, I don't know, offering something in return? (React-Native's ecosystem isn't even remotely worse than average, you're just looking at it in absolute terms: the more popular a framework is, the more people will create tooling around it, and so the more stale projects you run into. If you rely on packages not going stale, and your company literally makes money thanks to them, be that directly or by helping you put out your name so you can make those dollars, have an open source budget, and use it)

avg_dev 4y ago

i believe that software design is really hard. it seems appropriate to mention "conceptual integrity" which is a term i believe was coined by the (recently) late great fred brooks. his book "the design of design" talks about it a lot and i really found the discussion helpful. here is a very brief summary from his earlier book: https://en.wikipedia.org/wiki/The_Mythical_Man-Month#Conceptual_integrity https://en.wikipedia.org/wiki/The_Mythical_Man-Month#Concept... sometimes saying no is the right thing to do. as an aside, i find it a little distasteful that the author of this blog post chose to call projects out by name. these people are putting their efforts out for free and they are, to my eyes, taking flak for doing so.

that_guy_iain 4y ago

I say this nearly every time something like this is posted. The isn't isn't so much open source, it's that no one is getting paid. We're constantly relying on projects that we get for free where in esscence we're relying on goodwill. So much so, that people say don't add new features because you're depending on the goodwill of that contributor and they may disappear. Which is basically the same was the open source maintainer may disappear. Basically, this blog posts highlights why we should be paying for software libraries we use. All the downsides of proprietary code happens in open source. Open source projects don't add features you need, they can release a new version that has breaking changes and stop supporting the old version, they can just disappear, etc. However, the reality is, very rarely does popular proprietary just stop getting updated. While that happens in most somewhat popular open-source libraries. You can go to most mature open-source libraries and you'll see that the commit activity is down from when the project started. Many will say that's because it's feature complete. However, if you look at the open issues you'll see lots of activity. Often the issue is that the original maintainer has lost interest, be it because life - love affairs, children, sickness, etc, or that they've got a new hobby - arts, music, new tech, etc. I don't blame these maintainers, it's free and they owe me nothing. But at the same time I blame the industry for making it so common to build on these libraries that literally promise nothing for production code that you'll be extremely hard press to find a job that doesn't require you to build on top of FOSS. My prefered approach which I'm taking with my SaaS Boilerplate/General functionality bundle is use source-available license. Namely BSL - Business Source License with an additional grant that if you make less than $5k per month you don't need to pay. This allows the best of both worlds in my opinion. The ability to test it out, see it, use it for free in certain scenarios while making people who make money from it pay for it's maintenance. The full details of this license and approach can be read in the FAQ https://github.com/getparthenon/parthenon#faq https://github.com/getparthenon/parthenon#faq

dec0dedab0de 4y ago
The problem with paid proprietary code is that it almost inevitably devolves into a bloated mess of haphazard features being tacked on year after year by contractors who don't care about how hard it is to maintain, and don't even care if it works well because they don't need the code themselves, and the people buying the code don't use it, because they're buying it on behalf of a company and the people who actually use it just have to suffer through it. I think the one thing that would help open source more than anything else is if we outlawed contracts where the employer owns all copywritable material created by the employee.

sghosh2 4y ago

I wonder if having some sort of dependency scanner giving more upfront visibility would help clear things up. Then you'd be able to get a sense of what the composition of issues might look like. Seems like there's so many scanners out there that something must solve this.

Vanit 4y ago

Basically the same lesson can applied for saying no to feature requests from clients on your SaaS product; saying yes commits you to ongoing support, and you need to consider if it's worth it, particularly consider if said client is trying to outsource what should be bespoke work on their side, to you.