Open Source and Saying “No”
connortumbleson.com
connortumbleson.com
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.
Example from my own project: 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.
GitHub doesn't offer great tools to clearly separate bug reports, improvement suggestions and feature requests.
The problem is that even if you had multiple top-level distinctions, you would still have to make sure that people opening them are disciplined (and pay attention) enough to file them in the right category. Just because there's a separate "feature request" top-level tab doesn't mean that nobody will ever open a "bug" asking for a "feature". Especially if not everybody is allowed to ask for new features.
And I'm not even going into the difference between "improvement" and "feature" requests.
The difference is that they're all under the label "issues" implying it's something that needs to be fixed. Sure, you could label it, but that's a workaround and it's still in a category called "issues".
It's a neutral term.
I find it quite difficult to follow the discussion around a non-trivial feature request when it's just a regular issue.
When I hear the word "issue", I hear something roughly similar to "problem"; it certainly has a negative connotation. Maybe I'm just wrong, maybe I'm the only person in the world who associates "issue" with something negative. And even if I'm wrong, it still has nothing to do with marketing.
Since you don't like the connotations of word "issue", what word would you suggest to replace it? Keep it mind that it needs to be similarly broad and encompass not just bug reports and feature requests, but also documentation improvements, design discussions and more.
> Since you don't like the connotations of word "issue", what word would you suggest to replace it? Keep it mind that it needs to be similarly broad and encompass not just bug reports and feature requests, but also documentation improvements, design discussions and more.
Only if you want to keep everything about the UI the same except for the word used for what's currently called "issues". That's not something I have expressed any sort of desire for.
I am explaining that you are mistaken about the meaning of the term. I'm backed up by pretty much any dictionary you use to look the word up in.
If you don't dispute the literal meaning of the word, but think it carries a negative connotation, that is not a semantic issue.
> Only if you want to keep everything about the UI the same except for the word used for what's currently called "issues". That's not something I have expressed any sort of desire for.
We currently have a broad category of things, these things need to have a name. You seem to think that "issue" is a bad name for this category of things, so I am asking: what you think is a better term for this category?
We can further break down that category into "bug reports", "feature requests", "change requests", "discussions" and add better UI elements to surface those groups but the overall system that manages these all these items still needs a general name for what it is managing.
As a user it legitimately is an issue, in the commonly used sense, if you cannot do what you need to do with software, even if that software is working exactly as designed and no one has yet flagged some alternate functionality to add with an enhancement.
That's a you problem.
Ignoring the definition of issue (which also disagrees with your "negative" outlook), GitHub Issues, the product/feature, is clearly defined and encompasses things that deserve discussion, debate, or dispute.
A feature request is very much something that should be discussed.
> Maybe I'm just wrong,
Yes, you are. Rather than push back, accept it and move on.
Except that GitHub Issues originally only encompassed bugs. Labels weren't added until later that allowed you to filter by "type". Also, GitHub Discussions are for discussions, not GitHub Issues. GitHub themselves say that Issues is "often referred to as GitHub's bug-tracking system", so I wouldn't say that it's so "clearly defined".
https://docs.github.com/en/get-started/quickstart/communicat...
That quote is directly below a quite clear explanation of what issues are for: "are useful for discussing specific details of a project such as bug reports, planned improvements and feedback."
Each project can decide for themselves at where they draw the line in terms of what they want where. That is a good thing, it makes github issues flexible for a wide range of projects that are organized in a wide variety of manners. It seems like a shame to lose that flexibility to make it easier for people who are too lazy to do more than look at the count of open issues when evaluating the health of a project.
A healthy project can also close feature requests they don't want to implement. They can also choose to close every issue that isn't a bug report because they use different tools for feature planning and discussion. They can also choose to just automatically close every issue because they don't use github issues at all, but prefer other tools.
Because when you go in the issues tab, you then choose to only see "bugs", which will show you the one that needs handling, and you can ignore the 999 others.
But no, the wording isn't the only/main issue IMO, it's the lack of a clean separation between problems which should be fixed and non-problems which don't need to ever be resolved. It's a cognitive thing for maintainers, I believe mixing up those things contribute to burn-out through the purely psychological effects of being told by the UI that there are 100 things which need to be solved when there may in fact only be 5, it's a public perception thing when the stat that's prominently placed on the repo page is the number of open issues.
And yes, it's vague. It's not the technical lack of a good enough labelling and search system. And maybe different people react differently to this stuff, maybe some people have no trouble dealing with the lack of a clean separation. But given the fact that burn-out in open source is such a huge issue, maybe conflating the stuff which must be fixed and the stuff which doesn't have to be fixed isn't such a great idea.
If all you are saying is that it is a UI issue to mix those two categories when you open the issues page for the first time, it is pretty easy to bookmark or link to a list of issues filtered by label.
If that doesn't relate to what you are saying in anyway... then I am really unclear on what you are trying to say
That's just changing how GitHub presents the "issues." They could just as easily remove the global number display and simply display the count of each type of issue on the issues page.
> When you click the Issues tab, GitHub shows you all the feature requests you don't care about until you manually go and filter them out.
That's just a UX/UI concern. You can easily link to feature requests only.
None of these are "issues" related, but rather, just how it's displayed. Your concern is with the visuals.
You mean, until you manage your project...gasp. How horrible!
Some projects can rack up that many request quickly and overwhelming the maintainer but that isn't the norm. Warranted or not this kind of buildup is usually a sign of neglect.
There you go. That’s the problem.
Filtering by tag only takes a single click. It's not hard.
But if you want to implement a clear separation, you have to actually find a way of defining the separate categories, documenting how they are different, which to use when, and once you're done, it's a not a given that whatever categorization you've settled upon for your project would work for mine.
I think it's a fine trade-off to have something generic, and let each project add whatever tags work for it.
I wouldn't be against renaming "issues" to something more "generic". Maybe "change requests"?
* Separate "Issues" and "Requests", give each their own tab in the top-level UI. This creates a relatively clean separation between what requires attention because something is broken and what can be ignored until you want ideas for what features can be added or otherwise improved. Maybe GitHub doesn't need anything more generic than this.
* Have a category system, where the maintainer can create their own issue categories. Put these categories, with the number of entries in each category, in the sidebar, so that that's what people see rather than the one "Issues" number.
Maybe both of those solutions are bad and a good UX designer (not a random commenter on HN who has thought about this for 2 minutes) can think of something better. Maybe both of those solutions are bad and there is no good solution and the current approach is the best possible. I don't know. Notably though, "there is no solution to the problem that's not worse than the problem itself" does not mean the same as "there is no problem".
And then we also need to separate tab for discussions and questions since those are also very common use cases for issues.
> Have a category system, where the maintainer can create their own issue categories. Put these categories, with the number of entries in each category, in the sidebar, so that that's what people see rather than the one "Issues" number.
The only part of this that doesn't exist is a tab that links directly to the labels page, which does show the number open/closed issues per label
It seems like the problem you are trying to solve is potential users quickly dismissing projects with too many open issues. I would agree that looking just at an open issue count is not the best way to assess the health of a project. I think you are better looking at open issues will un-merged pull requests and why they aren't merged. You can also look at a sample of open issues to see how organized and responsive the developers are and what types of bugs tend to be present. All of these require far more effort than just clicking over to the issues tab and then clicking into the labels page to see a breakdown of open issues by label. I would say that users that don't take the effort to do this basic research of before pulling in a dependency aren't the high value users that will help contribute to the value of the project.
No. The issue I am talking about is that there is no clear separation between things which must be addressed (bugs) and things which don't (feature requests). There is no possible way I could have made that more clear. I have repeated this in almost every comment on this topic. You seem to be intentionally misunderstanding me at this point.
The distinction between "things which must be addressed" and "things which don't" doesn't map cleanly onto the distinction between "bug report" and "feature request" and there are also issues that don't fall cleanly into either category.
Examples:
1) A user opens an issues because a library doesn't work properly on platform X and fails with an error message. The developer of that library closes that issue with a "won't fix" because they don't support the platform. Is this a bug report or a feature request?
2) A user opens an issues because one of the dependencies of a library is no longer being developed so won't support moving to the new version of the language the library is written in. Is this a bug report or a feature request?
3) A project owner opens an issue because a new standard has been released that the library has to support because it is critical to it's ability to interoperate with other parts of the software ecosystem. This could well be much higher priority than many minor edge-case bugs, but is still new functionality.
The answers to these questions can, and should, vary from project to project and issue to issue depending on the larger context. An issue tracking system should be flexible enough to encompass these different needs.
I charitably assumed you were focused on "potential users quickly dismissing projects with too many open issues" since that at least provides a clear reason for why the current methods of categorizing issues isn't good. Since that assumption was incorrect, I still don't understand exactly what exactly your issue is with github issues.
You've repeatedly conflated categorization of issues based on priority and categorization of issues based on relation to the spec. Just because something is a bug report doesn't mean it needs to be fixed and just because something is a new feature doesn't mean that it shouldn't prioritized over bugs. Ignoring this simply serves to keep the conversation running in circles.
>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?
It was explicitly built to not be a tracker, but a discussion platform. The documentation describes them thus: "Discussions are for conversations that need to be transparent and accessible but do not need to be tracked on a project board and are not related to code, unlike GitHub Issues."
Thus, once a discussion needs to be tracked or linked to code changes, an issue is required. I'm in favor of providing more tools to orgnizations, but in practice I see very few to none of the projects that I depend on or interface with that actually use github discussions (I presume that is because so many discussions eventually need to be tracked or linked to code changes.)
> It's used extensively for that purpose at Github
Yet, when I look at the Discussions discussion, it's full of random junk, much of which looks like poorly written bug reports.
Without looking into the details I could assume these are 65 bugs.
Looks at a simplistic number without digging into the details will always be a poor way to evaluate the health of a project.
Since Github default culture is to use issues in a certain way, in which the maintainers are actually the bottleneck, most people will keep using it thinking it's the standard and correct way to do it.
Unrelated to the above, you mentioned the paid extra feature, I really wish to see this implemented in a source forge to see how it goes.
https://github.com/terrastruct/d2/issues
We actually switched from Linear to Github Issues because of how nice it is to have the TODOs colocated with PRs and code.
I suspect some users may drive by and be turned away from the sheer number of open Issues, and that's okay to me. I hate projects that try to keep Issues to 0 -- especially the ones that auto-stale. It just makes it harder for me to see if the Issue was actually resolved or not.
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.
Easy response: "OK... to going elsewhere."
This is well said. Maintainers need to grow their communities by allowing contributors to take ownership of components (this can be done with technical things like modular design that predicts future ways that things will be used, or by building good relationships with contributors), and they also need to have a clear vision for the things that their project is and is not.
It’s definitely a balance because if you are perceived as saying no too much and the community doesn’t understand or doesn’t accept your reasoning, then the project may stop growing and you’ll have less help to build the things you want to build.
Sometimes it's less to due with lack of ability and more to do with wanting some one else to pay the cost.
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.
However, humans being humans egos etc get in the way.
So maybe you should be integrating your work into my project.
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
I have no problems with open source maintainers charging for software, but I think the bigger problem is people having incorrect expectations of the open source model.
The main point of the open source is that if the software isn't doing what you need, then you can fix it yourself. Developers often act so helpless when it comes to dealing with bugs or missing features in their open source dependencies. Obviously that involves work, as you can't rely on some third party to maintain the software (or at least your fork) for you. On the other hand, you can't always rely on the vendor of proprietary software either. But at least in the open source model you can rely on yourself, and you can still incorporate any upstream improvements that do come along.
In my view, if you are releasing software as open source then it should have "paid for itself" in some way. Perhaps it was internal software that is used at your company, or perhaps it was written to scratch your own itch. In either case, the work is done and the cost is paid, and you are just sharing it because there's no added cost to you and maybe someone else will benefit from having the source code.
As a final note, it's not just the goodwill of open source maintainers that we are relying on - we also depend upon their desire for status. Being a maintainer of a popular open source project is high status, and something many people covet. That's why many maintainers will put in so much uncompensated time and put up with demanding users: they want the status that comes with having an "important" open source project. Smart maintainers will either learn how to profit from that status or learn how to tell demanding users (politely) to "fork off".
Here comes the issue, what if it can't get incorporated upstream? You end up with your own custom fork. With third-party corporate code, you can nearly always pay for them to add a feature. Very rarely will a company say there is no price high enough for them to add a feature. This is so common that the pricing is pretty much standardised, nearly every company I've worked for when adding features for customers charge the same 1 thousand euros per developer day of work.
Source available via BSL still allows for the modification of the code to customise it. So that benefit is still there.
> In my view, if you are releasing software as open source then it should have "paid for itself" in some way. Perhaps it was internal software that is used at your company, or perhaps it was written to scratch your own itch. In either case, the work is done and the cost is paid, and you are just sharing it because there's no added cost to you and maybe someone else will benefit from having the source code.
The real cost of software is maintaince. Updating it to keep it working with newer versions of x,y,z. etc.
> As a final note, it's not just the goodwill of open source maintainers that we are relying on - we also depend upon their desire for status. Being a maintainer of a popular open source project is high status, and something many people covet. That's why many maintainers will put in so much uncompensated time and put up with demanding users: they want the status that comes with having an "important" open source project. Smart maintainers will either learn how to profit from that status or learn how to tell demanding users (politely) to "fork off".
Not all projects are considered popular even though they're widely used. You may end up using a very rare but very important library to do something that not many people are doing. Not everything is sexy, especially when it comes to libraries you need for work.
You can also almost always pay for someone to maintain a custom fork for you, if you don't want to do it yourself.
I think I was unclear. My point was not that you could merge your own fork into the upstream, it's that you could merge any changes from upstream into your own fork. My point is that yes, you are maintaining your own fork, and while maintaining a fork is work, it is a valuable option that people forget about and yet is one of the key motivations behind open source to begin with.
> With third-party corporate code, you can nearly always pay for them to add a feature.
I have seen developers refuse to fix bugs in software that costs literally millions of USD in licensing. But beyond that, there is always the possibility that the software ends up with no maintainer, and even for the source code to be lost completely. Open source hedges against that risk.
> Source available via BSL still allows for the modification of the code to customise it. So that benefit is still there.
That's good. You'll see no objections from me. I don't really care much personally how people choose to license their software. While I have mentioned some of the benefits of open source, my point is not that "open source is better" but it's that the problems people have with open source come more from bad expectations of how that model should work in the marketplace rather than a problem with open source itself.
> The real cost of software is maintaince. Updating it to keep it working with newer versions of x,y,z. etc.
There is no inherent obligation to maintain projects you have released as open source. The code is already out there. If people want to modify it to fix bugs or add features, they are welcome to do so. They can even share their changes with the world! The only maintenance costs in open source are those costs the maintainers choose to take on. If a maintainer chooses to update their software, then each of those versions is a release of open source code, and the guideline still applies. If you make a change in an open source project, the cost of that change should already be accounted for before you release it.
> Not all projects are considered popular even though they're widely used. You may end up using a very rare but very important library to do something that not many people are doing. Not everything is sexy, especially when it comes to libraries you need for work.
That's true, but doesn't undermine my point. The point is that the pursuit of status plays a role in why people contribute to open source (and why they put up with onerous user requests). They (consciously or not) hope that by contributing they will be seen as cool and smart by others (or at least others within a given clique).
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.
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.
(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)
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.
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.
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.
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.
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.
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.
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
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.
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?
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.
Better hope no security exploits are found when you’re in the middle of that process…
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.
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
Flask is split up into a few Pallets projects - Flask, Werkzeug, Markupsafe, Click, itsdangerous, Jinja2 - but they're all from the same stable group. This split makes them more useful as independent libraries, rather than one big framework.
Ditto two more (Alembic and SQLAlchemy) are also from a very stable group. It would be nice if Alembic used Jinja2 instead of Mako, of course, but it's a dev-time dependency and so it's lower risk in my opinion.
I agree that at the thing Django does (forms + a SQL database) it does it with fewer dependencies than Flask. But that doesn't mean Flask has loads of dependencies; it has an appropriate number for the task you're doing. I was more comparing Flask to actual dependency soup ecosystems[0].
[0] https://github.com/rizkimcitra/next-starter-blog/blob/main/p...
Examples: camera roll and / or camera integration, contact listing, deep linking _into_ the app, linking _out of_ the app, foreground or background push notification display (and subsequent routing on press), the list goes on and on. IMO, native development, even if you choose to go Kotlin / Swift path instead of react native, is extremely complex.
To be brutally honest, I too can fire up a linux box or container, install flask, and have my simple REST server up in a matter of minutes. The same cannot be said for all the example native features listed above.
Django has fewer dependencies than Flask.
(though in all fairness the dependencies Flask has were developed by the same author, thus in that sense, it is more like Django)
For example, Mastodon quote tweets, or viewing accounts follows and followers.
But backfilling old content, full followers and follows? These are indeed sorely missing.
Let alone the horrible Mastodon search.