12 ms·

The struggles of an open source maintainer

719 points by ngaut 7y ago

Bucephalus355 7y ago
IRS could help out Open Source projects and make it way easier for them to apply for grant money. But they make it very tough to get 5013c status. I’m for quite strict tax enforcement but that should be changed. Also of course private companies need to start stepping up and providing the often only small sums of money needed to fix these projects via bug bounties and fees to the maintainers.
sergiotapia 7y ago
I own a 2.3K star Github repository (https://github.com/sergiotapia/magnetissimo https://github.com/sergiotapia/magnetissimo), that while trivial in it's implementation, it's pretty useful to a ton of people. There are a few core contributors to the project now and a Discord server as well and everything in this article rings true to me. It becomes an obligation of sorts and you definitely feel like you're letting people down, especially when it comes to people who have taken the time to contribute and share feedback, let alone people who actually open PRs. What I think can help is having more core contributors with write permissions, share the load. Or be up front in your readme and say, "I only check this once a quarter".
- simonebrunozzi 7y ago
  FYI, it seems that your https://sergio.dev/ https://sergio.dev/ is down.
  - sergiotapia 7y ago
    Thanks - it's not set up yet, I'm trying to figure out a free blogging solution that requires zero code (like Hugo and such), more like hosted Wordpress for free.
peterwwillis 7y ago
I think people are getting way too upset over GitHub features like issues & PRs, and the desire to please others. If you work on an open source project and you're not getting paid for it, you really need to divorce yourself from the demands of users. You have to assume that literally no one will use the software and just make it for yourself. If it becomes popular and you get feedback and contributions, great! Hopefully you can develop relationships that will lead to co-maintainers and such. But if it starts to feel like a struggle, just re-focus on what you want to get done, on your timeline.
- thrower123 7y ago
  Too many people aren't aware that you can say no, and not do something if you don't want to or if it is a bad idea. Especially if nobody is paying you. Even for people that are paying you for a product, sometimes you really need to say no, that is how it works, and no, we are not going to customize it for your particular workflow.
  - Matumio 7y ago
    Just saying "no" already can cost too much effort, because it involves making a decision that you'll want to justify. It takes effort to report an issue and even more to make a pull-request, so you don't want to reject them without a good reason, without really understanding it. Except for some obviously sloppy reports that would be just rude. The easier option is to simply not respond. Even this leaves some level of stress, because we've all had our own bug report or pull request ignored. We don't want to this uncaring person on the other side. But sadly, ignoring other people's requests is the best option for involuntary maintainers to protect themselves. The final option is to just hand out the keys to whoever is the most active contributor, and stop trying to control the direction of the project. This will get the stress-level down. You may not like this option, but it's much better than burning out.
mholt 7y ago
Man. I can relate. Open source projects are roller coasters. It's great when loads of people start using it... and terrible at the same time. It's validating to see people using your work, but sometimes you just want to submit your paper to NIPS rather than deal with what you think in the moment (and, frankly, in hindsight too) is a dumb issue: https://github.com/mholt/caddy/issues/1680#issuecomment-302719323 https://github.com/mholt/caddy/issues/1680#issuecomment-3027... I wrote up my experience from one wave of negativity a couple years ago: https://caddy.community/t/the-realities-of-being-a-foss-maintainer/2728 https://caddy.community/t/the-realities-of-being-a-foss-main... It still haunts me to this day, but my attitudes are finally trending more positive about the whole thing.
- kbenson 7y ago
  One of the major benefits of Open Source is that the user doesn't need to get a hold of the developer. It's always possible (or should be, if they're leveraging open source well) to patch a problem locally and build a fixed version their self. If they don't have the ability to do so, they really should at least have someone they can contact and pay (probably an exorbitant amount if it's an emergency) to do that for them. It's the open source equivalent of an application support contract or warranty.
  - voltagex_ 7y ago
    How would you go about finding someone to contract and pay for say, Firefox?
    - mathnmusic 7y ago
      Some folks I know are building polyglot.network as a FOSS-only software development agency. Early stages but you might wanna check them out.
      - voltagex_ 7y ago
        Site's down / unresolvable. Sounds good - I'd work for them.
smitty1e 7y ago
1. I've never upped my game enough to contribute to a project, much less put something on github. So, to the vast swath of people who are cooler than I: thank you. 2. TFA really gets at the classic issue of working vs. managing. Technical people tend toward being better at the former. Context switching between doing the work and managing the work is hard. Punting the management and diving into the work almost seems an escape. 3. The code itself makes this point to us. We can define an integer, and there it is. But when we need a list of integers? Look at how the management required just exploded. 4. Management sucks, but a management vacuum is a void, indeed. Let us be thankful for managers who don't suck.
- DannyBee 7y ago
  (I've been in the situation he describes, unfortunately) I agree a lot of that article feels like two things (but i'm not going to remove all nuance - there are clearly other issues): 1. The issue of being forced to be a manager when you want to be an individual contributor, and even worse, feels like being forced to be a TLM when you want to be an individual contributor. 2. Even if you take away the aspects of #1, it feels like a lack of notion that individuals don't build software past a certain point. I mean that in the sense that, IMHO, past a certain point, all software becomes team built (or fails), whether you are the manager or not. High level software engineering is a team sport, not an individual one. That is true even outside of management - it's also about technically mentoring and growing the team that builds your software so you can rely on them instead of you (which is not just a manager task). Every person you mentor into someone capable of doing the kind of work you want done is going to increase productivity on the software a lot more than you trying to do it yourself. Over time, they will also be able to build your team. Over time and scale, if you don't have a team to rely on, and actually start relying on them, you will just feel crushed. Utterly utterly crushed. There is no path out of it that involves getting better yourself. You simply cannot scale past a certain point and there is no way out of it.
  - smitty1e 7y ago
    > High level software engineering is a team sport, not an individual one. #Truth Floating out there in the cloud, you have to be a DBA, a network engineer, a browser jockey, a middleware dev, a sysadmin, a security specialist, an architect. . . . . .and that's without being handed someone else's effort that is probably not in the desirable state for reasons you'll never know. It's blatantly obvious to even the most casual observer that anybody claiming to know "all that stuff" is having you on. That the internet works AT ALL is somewhat amazing when you ponder it.
Sir_Cmpwn 7y ago
I don't maintain anything as big as Redis, but I've faced many similar problems all the same and I think I have an approach which makes it palatable. I wrote about my approach at length here: https://drewdevault.com/2018/06/01/How-I-maintain-FOSS-projects.html https://drewdevault.com/2018/06/01/How-I-maintain-FOSS-proje... But the main thing is that almost all bug reports, feature requests, and so on, get sent to /dev/null. Users who care about a problem are expected to work on that problem themselves. In the case of software like Redis, pretty much everyone reporting a bug is also qualified to fix that bug, so it works particularly well. Then I focus only on helping new contributors get their bearings and making regular contributors happy and comfortable with their work on the project. So far this approach has been very successful for me - I don't get burned out, and neither do my contributors, and we have happy, healthy communities where people work at a pace which suits them best and aren't stressed or overwhelmed. Sure, lots of feature requests and bug reports get neglected, but I think the net result is still a very positive impact on the project. The occasional drive-by bug submitter provides far less value to the project as someone who writes even one patch. Focusing on keeping the people who create the most value happy makes for a more productive project and a better end result. Some people are put out by the fact that their bug report, feature request, etc goes unanswered, but I can quickly put the guilt out of my mind by reminding myself that ignoring them is doing a benefit to the project. And in practice, I generally have time to give people some words of encouragement and a nudge in the right direction towards writing a patch without burning myself out.
- tda 7y ago
  I found the writings of Peter Hintjens (creator of ZeroMQ) very inspiring, where he describes the merits of Optimistic merging (OM). Quoting at length from http://hintjens.com/blog:106 http://hintjens.com/blog:106: Standard practice (Pessimistic Merging, or PM) is to wait until CI is done, then do a code review, then test the patch on a branch, and then provide feedback to the author. The author can then fix the patch and the test/review cycle starts again. At this stage the maintainer can (and often does) make value judgments such as "I don't like how you do this" or "this doesn't fit with our project vision." In the worst case, patches can wait for weeks, or months, to be accepted. Or they are never accepted. Or, they are rejected with various excuses and argumentation. PM is how most projects work, and I believe most projects get it wrong. Let me start by listing the problems PM creates: It tells new contributors, "guilty until proven innocent," which is a negative message that creates negative emotions. Contributors who feel unwelcome will always look for alternatives. Driving away contributors is bad. Making slow, quiet enemies is worse. It gives maintainers power over new contributors, which many maintainers abuse. This abuse can be subconscious. Yet it is widespread. Maintainers inherently strive to remain important in their project. If they can keep out potential competitors by delaying and blocking their patches, they will. It opens the door to discrimination. One can argue, a project belongs to its maintainers, so they can choose who they want to work with. My response is: projects that are not aggressively inclusive will die, and deserve to die. It slows down the learning cycle. Innovation demands rapid experiment-failure-success cycles. Someone identifies a problem or inefficiency in a product. Someone proposes a fix. The fix is tested and works or fails. We have learned something new. The faster this cycle happens, the faster and more accurately the project can move. It gives outsiders the chance to troll the project. It is a simple as raising an objection to a new patch. "I don't like this code." Discussions over details can use up much more effort than writing code. It is far cheaper to attack a patch than to make one. These economics favor the trolls and punish the honest contributors. It puts the burden of work on individual contributors, which is ironic and sad for open source. We want to work together yet we're told to fix our work alone. Now let's see how this works when we use Optimistic Merge. To start with, understand that not all patches nor all contributors are the same. We see at least four main cases in our open source projects: Good contributors who know the rules and write excellent, perfect patches. Good contributors who make mistakes, and who write useful yet broken patches. Mediocre contributors who make patches that no-one notices or cares about. Trollish contributors who ignore the rules, and who write toxic patches. PM assumes all patches are toxic until proven good (4). Whereas in reality most patches tend to be useful, and worth improving (2). Let's see how each scenario works, with PM and OM: PM: depending on unspecified, arbitrary criteria, patch may be merged rapidly or slowly. At least sometimes, a good contributor will be left with bad feelings. OM: good contributors feel happy and appreciated, and continue to provide excellent patches until they are done using the project. PM: contributor retreats, fixes patch, comes back somewhat humiliated. OM: second contributor joins in to help first fix their patch. We get a short, happy patch party. New contributor now has a coach and friend in the project. PM: we get a flamewar and everyone wonders why the community is so hostile. OM: the mediocre contributor is largely ignored. If patch needs fixing, it'll happen rapidly. Contributor loses interest and eventually the patch is reverted. PM: we get a flamewar which troll wins by sheer force of argument. Community explodes in fight-or-flee emotions. Bad patches get pushed through. OM: existing contributor immediately reverts the patch. There is no discussion. Troll may try again, and eventually may be banned. Toxic patches remain in git history forever. In each case, OM has a better outcome than PM. In the majority case (patches that need further work), Optimistic Merge creates the conditions for mentoring and coaching. And indeed this is what we see in ZeroMQ projects, and is one of the reasons they are such fun to work on.
souprock 7y ago
He missed a big one: you have no way to stop Linux distributions from hacking up your software, and you'll suffer the consequences of whatever they do. I hit this with procps. (a package with ps, top, vmstat, free, kill...) It was horrifically demotivating, helping to end my involvement as the maintainer from roughly 1997 to 2007. (the other big issue was real life intruding, with me joining a start-up and having 5 kids) I had plans for command line option letters, carefully paying attention to compatibility with other UNIX-like systems, and then Red Hat would come along and patch their package to block my plans. They were changing the interface without even asking for a letter allocation. I was then sort of stuck. I could ignore them, but then my users would have all sorts of compatibility problems and Red Hat would likely keep patching in their own allocation. I could accept the allocation, letting Red Hat have control over my interface. Red Hat sometimes added major bugs. I'd get lots of complaints in my email. These would be a mystery until I figured out that the user had a buggy Red Hat change. Patches would often be hoarded by Linux distributions. I used to regularly download packages and open them up to look for new crazy patches. Sometimes I took the patches, sometimes I ignored the patches, and sometimes a wrote my own versions. What I could never do was reject patches. The upstream software maintainer has no ability to do that. The backlog of unresolved troubles of this sort kept growing, making me really miserable. Eventually I just gave up on trying to put out a new release. That was painful, since I'd written ps itself and being the maintainer had become part of my identity. Letting go was not easy. Maybe it had to happen at some point, since I now have more than twice as many kids, but I will be forever bitter about how Red Hat didn't give a damn about the maintainer relationship.
- cyphar 7y ago
  That sounds really awful, and it's really disheartening to see the (ex)maintainer of such a core piece of Linux distributions being treated that way. I work for a Linux distribution (SUSE) and I assure you that we don't all act this way. I've had to carry my fair share of downstream patches in openSUSE/SUSE packages, but I always make sure to submit the patches upstream in parallel. Quite a few people I know from Red Hat (and other distributions like Debian, Ubuntu, etc) do the same. It's possible that times have changed since then, or that it depends which package maintainers you are dealing with, but I hope it hasn't soured your opinion of all Linux distribution maintainers. One thing that is a constant problem is that users of distributions keep submitting bugs to upstream bug-trackers. If there was one thing I wish I could change about user behaviour, it would be this. Aside from the fact that the bug might be in a downstream patch (resulting in needless spam of upstream), package maintainers are also usually better bug reporters than users because they are more familiar with the project and probably are already upstream contributors.
burtonator 7y ago
I'm threading the needle in a project I've been working on which is both Open Source and has premium features around cloud sync: https://getpolarized.io/ https://getpolarized.io/ ... it's been interesting. I'm trying to give everyone the best of both worlds but since I'm catering to a large user base I have to make sure to keep everyone happy. Some people DO NOT want to do anything cloud. Some want their own cloud. Others want cloud and they want it easy. I think part of what I'm learning is that in order to get the trust from users I'm going to either have to be around for a long time or get the thumbs up from other organizations that can vouch for my positive intentions. For example, I want to write up a document about our commitment to Open Source but of course that takes work and I don't have a ton of time.
- jakeogh 7y ago
  Hey nice! I was not expecting to click that and get a working page without JS!
- analognoise 7y ago
  There was a pop-up that asked for money. The language of the bar at the top gives the impression the program will go away soon unless money comes in, plus the fact that someone was willing to inject pop-ups made it very difficult to trust - what if it goes commercial and someone is willing to inject ads or malware?
sheetjs 7y ago
We (https://sheetjs.com https://sheetjs.com) maintain some reasonably popular projects (our most popular, https://github.com/SheetJS/js-xlsx/ https://github.com/SheetJS/js-xlsx/, has over 15K stars and sees millions of downloads per month). It's important to remember why you are involved in open source. If those circumstances change, you should ask why you continue to remain involved. As soon as you lack a satisfactory answer, it's your cue to stop. Many large open source projects start out as a passion project or a solution to a specific problem that the original developers faced. Over time, other people face similar issues and rally around your solution and it is really easy to fall into the trap of bearing their burdens. This is a bad response. Other people using your open source offerings do not create any sort of obligation on your part to care or respond to their concerns. If someone really cares enough, they will incentivize your continued effort (like money or other considerations). It is unfortunately cultural taboo to ask some of the more vocal critics to pay, but setting up that dialogue at least shuts down most of the comments. IMHO the origin of most of these issues comes from the very thing that drives many people to open source in the first place: personal branding. If you remove your personal identity from the equation, it's a lot easier to "turn off notifications". Rants and criticisms are directed at this mystery character, not you personally. Since you are not personally tied to the project, working on open source feels like a distinct activity and is judged on its merits. You don't feel the same sense of obligations since you don't personally feel like you are disappointing the user base.
- Sean-Der 7y ago
  The sunk cost (maybe wrong term) is really tough. It is hard to walk away because you have put so much effort in. Especially if you don't have a company behind a project it will probably falter. I really enjoy Open Source 99.99% of the time. But that 0.01% I just remember how much work I put in.
- chii 7y ago
  > trap of bearing their burdens yep, don't bear other people's burdens without asking for money, or contributions (of labour - such as code)
- ralphstodomingo 7y ago
Sean-Der 7y ago
I have only been doing Pion WebRTC(https://github.com/pion/webrtc https://github.com/pion/webrtc) for a year, but the hardest ones for me have been * Relationships tied to the project It sort of burned me out when the first contributors moved on. I have always been on the other side though, interests change or you change jobs. * Every user issue is urgent. It is hard figuring out what the most important thing to work on is. If a user takes time to file an issue it is causing them issues. I just have been on the other side and it doesn't feel great to be ignored. * Community members with different communication styles People aren't so much assholes, but just communicate differently. It is really hard to mediate, no one is at fault but I just hate seeing people leave/get burned out from it.
- cerberusss 7y ago
  As to hard figuring out what the most important thing to work on is: I have some code on Github and got a change request. I just replied that I can do it for my currently hourly rate. That makes priorities clear.
  - Sean-Der 7y ago
    I don't want to bring money into it though. It personally makes me happy that is free of any financial pursuit. It is nice to suspend disbelief and just all work together on making things that make people happy :)
    - cerberusss 7y ago
      Yeah, sometimes money takes away the joy :)
- imetatroll 7y ago
  This is really nice. I wrote my own (probably bad) webrtc implementation for a personal project using gopherjs months ago. If I ever switch that project to webassembly, I will take a look at pion. Thanks for your efforts!
nerdbaggy 7y ago
I don’t know why so many open source users feel so entitled when they have done nothing for the project. I believe that anybody can help a project from code, documentation, financial, graphic design, etc.
- MakeUsersWant 7y ago
  Most projects don't actually want help. Go and try it: report a few bugs or point out usabilty issues. See what happens.
  - thethirdone 7y ago
    Most of my bug reports have been very well accepted. The worst response I can remember is just not responding for like 3 months. And on the other side as a maintainer, any bug report that demonstrates a clear issue (crash, hang, etc) with a reproducible setup is appreciated. What can be really frustrating are bug reports that aren't bugs and a better understanding of the software would allow them to solve the problem. For example, there was one issue on Slic3r that was asking for a PDF output of config files. There is really no reason to do that.
  - PeterisP 7y ago
    That's not really help that contributes to the project, that's communication or (often in the case of usability issues) opinion that might be useful, and even if it is, it just piles on more work on the project instead of helping with that work. Every project has accepted everything whenever I've actually tried to help with the actual work they're doing, i.e. solving a bug or submitting a pull request fixing some documentation, something that reduces their todo-list instead of adding to it.
bowmessage 7y ago
O/T, not meant to be rude, but under what moral framework do you find it reasonable to bring more than 10 children into this world?
- cheschire 7y ago
  I find that when people preface a statement with a negation, it has the opposite effect and draws focus to that aspect. "With all due respect," or "no offense but," or "not to be rude but..."
  - sah2ed 7y ago
    That may be true, but I think the poster didn't frame their actual question charitably enough, causing the phatic expression prefacing the question to be rendered completely useless. IMHO, it was quite confrontational if you mentally leave it out: "... under what moral framework do you find it reasonable to bring more than 10 children into this world?"
- deleted 7y ago
  [deleted]
- dang 7y ago
  Please don't accost someone personally like this on HN. We detached this subthread from https://news.ycombinator.com/item?id=19936320 https://news.ycombinator.com/item?id=19936320 and marked it off-topic.
tlrobinson 7y ago
> Sometimes I believe that software, while great, will never be huge like writing a book that will survive for centuries. Note because it is not as great per-se, but because as a side effect it is also useful… and will be replaced when something more useful is around. That's an interesting point and thought experiment: what piece of software currently exists that will still be widely used in a century? And what's the oldest software that's still being used currently?
- jonathanberger 7y ago
  Unix. Email. TCP/IP. Just taking an initial stab.
  - kbwt 7y ago
    All of those will be around not because they are good, but because so many other things are built against their interfaces.
    - aeorgnoieang 7y ago
      Ultimately, what else is 'good' other than being the foundation of further far-flung flourishing?
  - gloflo 7y ago
    Those are standards and protocols, not software.
- BillGates432 7y ago
  Spider Solitaire
- sanxiyn 7y ago
  > And what's the oldest software that's still being used currently? I am very interested in this question, but much of software is proprietary and you don't have much visibility into their history. For software in the public, trivial lower bound is GCC 1.0 in 1987. Another case I know is Community Climate System Model, in continued development since 1983.
jondubois 7y ago
I've been maintaining my OSS project for almost 6 years. It's well used in the industry but nowhere near as popular as Redis. But I can relate to pretty much everything in the article even the thinking approach. It makes me think that it takes a certain personality to be an OSS developer.
austincheney 7y ago
I encountered most of the issues described so I set out to solve this problem. I did the horrible bad thing: I rewrote my projects from scratch. It took me about a year, pretty much all of 2018. I could afford to do this because I was separated from both work and family by military education and a military deployment immediately following. Now I have software that is stupid fast to extend and maintain. My software now executes faster than comparable applications coming out of Facebook with more options and at a very tiny size after accounting for dependcies. Now I finally have time to watch all the shows I have missed and play games since my software has fewer defects compared to similar applications and is faster to patch. I did get tired of the asshole factor though and even deleted my Reddit account as a result. Now it’s harder to promote my software online but deleting my reddit account again opened up more personal time.
monksy 7y ago
It sounds like this is similar to the harassment that he received over redis using the terms "master"/"slave". (Even DHH jumped in and used his platform to harass) http://antirez.com/news/122 http://antirez.com/news/122 For someone that is giving parts of their life to help others, the amount of entitlement that people expect is unbelievable.
stupidcar 7y ago
It's ironic that Git was intentionally designed to decentralise the process of software development, so that there was no single "blessed" repository, but instead of a network of peers, each of which could evolve at a different rate and in a different way, with the community deciding which would "win" in terms of popularity. And yet, via Github, the community has reinvented the centralised model of software development. For any project, there is a single instance that is the "blessed" version, by virtue of having the most stars or collaborators, or owning the associated package name. 99% of forks are nothing more than a place where you create a feature branch that you intend to PR to the blessed project. I hope that, one day, somebody invents a git-based project ecosystem that solves the problem of decentralised project management. I don't know exactly what this would look like, but I think it would need to embed the idea of community and contributor consensus and democracy at a fundamental level, separating the concept of the project and project ownership from any individual fork.
- djangovm 7y ago
  i am wondering this probably because of two factors: 1. accountability: where do I go looking if something is broken? 2. and discoverability: where to search, and whom to believe as being the correct owner of the copy of the codebase. this is similar to block-chain currency (based on my limited understanding.. correct me if i am wrong). While it is meant to be decentralised, entities like coinbase effectively create a central entry/exit point somewhere in the ecosystem.
  - dzmien 7y ago
    I immediately thought of Bitcoin when reading the OP. It can, and has been "hard" forked via miner consensus. That is, of course, one level removed from git, but I guess git"hub" could be more like gittorrent or something where instead of hosting a repo on one central server, the repo is hosted by a swarm and the version with the most seeds is the winner.
- albertzeyer 7y ago
  But it does help for decentralized development, or not? And you have this single instance of authority in almost all cases? E.g. for Linux itself, you also have that, and Git was developed for Linux. I think the issue is more about how to structure pull requests, issues, etc., in a better way (maybe hierarchical), such that this matches the exponential number of more communication. GitHub does not help too much with this, but it also does not really fight against this. This is basically a problem every big project has to manage in some way. For comparison, I would look at other big projects like TensorFlow, Firefox, Chromium, Linux, CPython, etc.
bluehatbrit 7y ago
For those struggling to access the site: https://archive.fo/10IpE https://archive.fo/10IpE
bmh 7y ago
It seems like there's an opportunity for a tool to help solve this (ie something other than GitHub issues).
- aeorgnoieang 7y ago
  I'm sure different tools could help somewhat but ultimately anything replacing GitHub issues would still involve some kind of social, i.e. communication, structure and that's just a hard thing to build and maintain.
dullgiulio 7y ago
Salvatore's feeling that he should be thinking about big ideas makes me think of Fabrice Bellard. He drops amazing things, let's the community manage them and concentrates on starting the next amazing thing. Maybe that's something good for Salvatore too.
marknadal 7y ago
So very true! I also maintain 10,000+ GitHub starred OSS database (https://github.com/amark/gun https://github.com/amark/gun), and can relate to a lot of these points. Worse than the jerks, though, are the bike-shedders. It is emotionally much easier to confront jerks, even though it is hurtful. But the people who "Why isn't this written in X language?" or "Here's a PR to turn tabs into spaces" are honestly well-intended but naive and short-sighted. Explaining to those people why you have to reject their PR because it provides no additional value and is purely an arbitrary distraction takes quite a bit of time trying to be delicate, but is nearly as much waste of time.
dbnotabb 7y ago
We're working to address some of the issues raised in this piece, by creating a new way of working on Open Source. Companies post their issues on our platform and contributors are incentivised by getting to know a company, a monetary reward and the potential of raising their profile with the company to get hired. We're looking for feedback so if anyone has any thoughts - https://works-hub.com/issues https://works-hub.com/issues
- Crinus 7y ago
  Others have tried what you seem to be trying and didn't work, how are you going to convince people who decide to use tech because it is free, to pay for it and pay for more than insultingly low scraps? And once someone does accept and the work is done, what happens if they are not the main developer of the software that was worked on and the developers decide they do not want to accept the work? Where does that leave your customers who most likely (especially if their initial major motivation was free stuff) wont want to pay someone fix/update the patches every time a new version is released nor be willing to have their own fork? I might be missing something of course since your site doesn't work. Every time i tried to click on a link nothing happened. Firefox's dev console had this warning: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.segment.io/v1/p https://api.segment.io/v1/p. Looks like your tracking is broken. BTW, i'm kinda curious, how come you have "25,000+ software engineers on WorksHub" but only 8 issues, all of them from your own company?
makecheck 7y ago
People seem to have a serious lack of understanding when making requests of others. - When you send an E-mail, at least imagine that the recipient may have literally hundreds of other messages to dredge through and the time required to respond (and detail of response) may reflect that. Not personal, don’t get mad at them. - When you send an “instant message”, it may be instant for you but for all you know the recipient is deep in the middle of something and won’t respond for awhile. Not personal, don’t get mad at them. - The recipient may be on the other side of the planet. Err on the side of extra information so you don’t wait days for a response that just has to ask you for more. - When you file a bug, “thank you but do some homework”. A person dealing with 1000 other things will not have time to hand-hold you through all the things you’re not telling them yet. Be precise and complete. Be reasonable about when/if to expect a fix. - And for that matter, in retail, or traffic, or 100 other things in life, you don’t know as much as you think you do about what other people are dealing with. Stop for a second. Imagine their situation. That person not instantly serving you and only you has a dozen other things going on.
- gppk 7y ago
  I agree with a lot of these. One thing i've noticed in life is that our use of aschynchronous communication methods is much more in a "respond now" fashion. Also as a contributor to StackOverflow your point about asking questions with the right amount of information is really spot on.
- senorjazz 7y ago
  > - When you send an “instant message”, it may be instant for you but for all you know the recipient is deep in the middle of something and won’t respond for awhile. Not personal, don’t get mad at them. People don't get it. If they said a DM / IM or any program which is considered a "chat" app they expect instant replies. I run a single person software company. I used to allow people to contact me for support any and all chat programs. So for paying customers you can magnify that "expect an instant reply" factor. People would get quite annoyed, regardless of whether it was Sunday, or 3am in the morning for me. For that reason, only email and forum support is no offered. Never had a complaint since about wait times. People expect to wait after sending an email. They expect to wait for a forum post. They do not expect to wait for a chat / IM / DM response.
sdegutis 7y ago
> Moreover I’m sure I’m doing less than I could because of that, but this is how things work. It doesn't have to be. What if all the people who "pay" for Redis, their money want into a collection bucket, and nobody got the money until they earned it. Then you work on your own schedule and "earn" that money at a fixed dollar rate per hour, and claim the money at the end. Other trusted contributors can join this effort and claim the money after working the hours. This way, hours are up to the contributors, and money is more like the "pledge" in Kickstarter for example, or a check that's not yet cashed.
jancsika 7y ago
This is a vicious cycle of a mentoring problem. If the maintainer never learned and practiced "role shifting" as a part of the developer process, they are going to have a bad time if the project gains any traction whatsoever. Worse, there's no easy way for a mentor to swoop in and teach them basic role shifting tactics. Because such an attempt would likely be interpreted as just a user giving yet another uninformed opinion. Edit: And such a maintainer is unlikely to be able to delegate to newcomers since mentoring isn't part of their skillset. (Thus the vicious cycle.)
adam1210 7y ago
I have a small (2k+ stars) niche game-related project. The hardest part for me is saying "no". If someone proposes a change that I think is out of scope, or is not something I want to maintain (maybe the introduced complexity is greater than the benefit of the feature) I find it difficult to explain that in a way people understand. Often times people get offended by it and then become angry at me, and over time it becomes very draining.
nicpottier 7y ago
> Sometimes I believe that software, while great, will never be huge like writing a book that will survive for centuries. Note because it is not as great per-se, but because as a side effect it is also useful… and will be replaced when something more useful is around. I once saw a sig somewhere that was something along the lines of the author's goal being of writing some piece of software that would outlive them. That seemed like a neat, but incredibly ambitious goal, very very few pieces of software will meet it. That said, Redis is probably one of them. It isn't too hard to imagine that there will be Redis instances running somewhere in 40 years, and though I wish antirez a long life, I think it is likely there will still be Redis instances chugging along after he passes. So be proud antirez! You've most certainly made a dent in the universe.
- redisman 7y ago
  Data migration is difficult. I'm sure there are a lot of very old databases still chugging along in some dusty office corner because no one wants to touch them since they've worked adequately for the last 30 years.
mamcx 7y ago
I don't remember if I get the idea elsewhere or what, but: "Worse than a failed project/business, is a successfully one" I part of "small scale" projects and one thing that some fear, very much, if that the project GET traction. This have killed some business before.
ilaksh 7y ago
I guess I will be the one to complain about something that makes me look bad. Since no one else complains about this, it makes me think I might be the only one. However I doubt that. The problem I have had with my open source projects so far is that most of them seem to not be very popular and they receive very little if any feedback at all. It's gotten to the point where I feel like popularity and merit are not even directly related. It seems like maybe part of it is tied to some kind of social networking popularity contest. Certainly I have to think that way otherwise I would never try to contribute anything again.
narnianal 7y ago
The best thing creators should do in my eyes, and I always do it myself, is trying to make yourself jobless. Solve that problem, find people who are good at maintaining stuff, move on to the next problem. You don't need to sit there looking through bugs 12 hours a day. In fact there are people who love this continuous struggle more than you, and who therefore also have developed skills at handling these situations without having sleepless nights. Find these people once your project reaches a stable point from a creative POV. Then help these people get started, not the users. Then you will see that you need to do less and less. And when you are at about 30% load start using your time to find the next problem that you can solve. No reason to be ashamed of either. There are loads of people who really love this continous lifestyle and there are few people who actually love finding a new solution to a problem that nobody can solve. Everybody will be more happy in the end, even the users. PS: You can also see it in a different way. There's not just jenkins and github and AWS to setup as a system to get your project running. People are also part of the system. People who move the issues along these pipelines. There is no system if people aren't part of it. And there are not just devs and users, there are also maintainers, communicators etc.
2easy 7y ago
Really great article bows down

719 points by ngaut 7y ago

IRS could help out Open Source projects and make it way easier for them to apply for grant money. But they make it very tough to get 5013c status. I’m for quite strict tax enforcement but that should be changed. Also of course private companies need to start stepping up and providing the often only small sums of money needed to fix these projects via bug bounties and fees to the maintainers.

sergiotapia 7y ago

I own a 2.3K star Github repository (https://github.com/sergiotapia/magnetissimo https://github.com/sergiotapia/magnetissimo), that while trivial in it's implementation, it's pretty useful to a ton of people. There are a few core contributors to the project now and a Discord server as well and everything in this article rings true to me. It becomes an obligation of sorts and you definitely feel like you're letting people down, especially when it comes to people who have taken the time to contribute and share feedback, let alone people who actually open PRs. What I think can help is having more core contributors with write permissions, share the load. Or be up front in your readme and say, "I only check this once a quarter".

simonebrunozzi 7y ago
FYI, it seems that your https://sergio.dev/ https://sergio.dev/ is down.
- sergiotapia 7y ago
  Thanks - it's not set up yet, I'm trying to figure out a free blogging solution that requires zero code (like Hugo and such), more like hosted Wordpress for free.

peterwwillis 7y ago

I think people are getting way too upset over GitHub features like issues & PRs, and the desire to please others. If you work on an open source project and you're not getting paid for it, you really need to divorce yourself from the demands of users. You have to assume that literally no one will use the software and just make it for yourself. If it becomes popular and you get feedback and contributions, great! Hopefully you can develop relationships that will lead to co-maintainers and such. But if it starts to feel like a struggle, just re-focus on what you want to get done, on your timeline.

thrower123 7y ago
Too many people aren't aware that you can say no, and not do something if you don't want to or if it is a bad idea. Especially if nobody is paying you. Even for people that are paying you for a product, sometimes you really need to say no, that is how it works, and no, we are not going to customize it for your particular workflow.
- Matumio 7y ago
  Just saying "no" already can cost too much effort, because it involves making a decision that you'll want to justify. It takes effort to report an issue and even more to make a pull-request, so you don't want to reject them without a good reason, without really understanding it. Except for some obviously sloppy reports that would be just rude. The easier option is to simply not respond. Even this leaves some level of stress, because we've all had our own bug report or pull request ignored. We don't want to this uncaring person on the other side. But sadly, ignoring other people's requests is the best option for involuntary maintainers to protect themselves. The final option is to just hand out the keys to whoever is the most active contributor, and stop trying to control the direction of the project. This will get the stress-level down. You may not like this option, but it's much better than burning out.

mholt 7y ago

Man. I can relate. Open source projects are roller coasters. It's great when loads of people start using it... and terrible at the same time. It's validating to see people using your work, but sometimes you just want to submit your paper to NIPS rather than deal with what you think in the moment (and, frankly, in hindsight too) is a dumb issue: https://github.com/mholt/caddy/issues/1680#issuecomment-302719323 https://github.com/mholt/caddy/issues/1680#issuecomment-3027... I wrote up my experience from one wave of negativity a couple years ago: https://caddy.community/t/the-realities-of-being-a-foss-maintainer/2728 https://caddy.community/t/the-realities-of-being-a-foss-main... It still haunts me to this day, but my attitudes are finally trending more positive about the whole thing.

kbenson 7y ago
One of the major benefits of Open Source is that the user doesn't need to get a hold of the developer. It's always possible (or should be, if they're leveraging open source well) to patch a problem locally and build a fixed version their self. If they don't have the ability to do so, they really should at least have someone they can contact and pay (probably an exorbitant amount if it's an emergency) to do that for them. It's the open source equivalent of an application support contract or warranty.
- voltagex_ 7y ago
  How would you go about finding someone to contract and pay for say, Firefox?
  - mathnmusic 7y ago
    Some folks I know are building polyglot.network as a FOSS-only software development agency. Early stages but you might wanna check them out.
    - voltagex_ 7y ago
      Site's down / unresolvable. Sounds good - I'd work for them.

smitty1e 7y ago

1. I've never upped my game enough to contribute to a project, much less put something on github. So, to the vast swath of people who are cooler than I: thank you. 2. TFA really gets at the classic issue of working vs. managing. Technical people tend toward being better at the former. Context switching between doing the work and managing the work is hard. Punting the management and diving into the work almost seems an escape. 3. The code itself makes this point to us. We can define an integer, and there it is. But when we need a list of integers? Look at how the management required just exploded. 4. Management sucks, but a management vacuum is a void, indeed. Let us be thankful for managers who don't suck.

DannyBee 7y ago
(I've been in the situation he describes, unfortunately) I agree a lot of that article feels like two things (but i'm not going to remove all nuance - there are clearly other issues): 1. The issue of being forced to be a manager when you want to be an individual contributor, and even worse, feels like being forced to be a TLM when you want to be an individual contributor. 2. Even if you take away the aspects of #1, it feels like a lack of notion that individuals don't build software past a certain point. I mean that in the sense that, IMHO, past a certain point, all software becomes team built (or fails), whether you are the manager or not. High level software engineering is a team sport, not an individual one. That is true even outside of management - it's also about technically mentoring and growing the team that builds your software so you can rely on them instead of you (which is not just a manager task). Every person you mentor into someone capable of doing the kind of work you want done is going to increase productivity on the software a lot more than you trying to do it yourself. Over time, they will also be able to build your team. Over time and scale, if you don't have a team to rely on, and actually start relying on them, you will just feel crushed. Utterly utterly crushed. There is no path out of it that involves getting better yourself. You simply cannot scale past a certain point and there is no way out of it.
- smitty1e 7y ago
  > High level software engineering is a team sport, not an individual one. #Truth Floating out there in the cloud, you have to be a DBA, a network engineer, a browser jockey, a middleware dev, a sysadmin, a security specialist, an architect. . . . . .and that's without being handed someone else's effort that is probably not in the desirable state for reasons you'll never know. It's blatantly obvious to even the most casual observer that anybody claiming to know "all that stuff" is having you on. That the internet works AT ALL is somewhat amazing when you ponder it.

Sir_Cmpwn 7y ago

I don't maintain anything as big as Redis, but I've faced many similar problems all the same and I think I have an approach which makes it palatable. I wrote about my approach at length here: https://drewdevault.com/2018/06/01/How-I-maintain-FOSS-projects.html https://drewdevault.com/2018/06/01/How-I-maintain-FOSS-proje... But the main thing is that almost all bug reports, feature requests, and so on, get sent to /dev/null. Users who care about a problem are expected to work on that problem themselves. In the case of software like Redis, pretty much everyone reporting a bug is also qualified to fix that bug, so it works particularly well. Then I focus only on helping new contributors get their bearings and making regular contributors happy and comfortable with their work on the project. So far this approach has been very successful for me - I don't get burned out, and neither do my contributors, and we have happy, healthy communities where people work at a pace which suits them best and aren't stressed or overwhelmed. Sure, lots of feature requests and bug reports get neglected, but I think the net result is still a very positive impact on the project. The occasional drive-by bug submitter provides far less value to the project as someone who writes even one patch. Focusing on keeping the people who create the most value happy makes for a more productive project and a better end result. Some people are put out by the fact that their bug report, feature request, etc goes unanswered, but I can quickly put the guilt out of my mind by reminding myself that ignoring them is doing a benefit to the project. And in practice, I generally have time to give people some words of encouragement and a nudge in the right direction towards writing a patch without burning myself out.

tda 7y ago
I found the writings of Peter Hintjens (creator of ZeroMQ) very inspiring, where he describes the merits of Optimistic merging (OM). Quoting at length from http://hintjens.com/blog:106 http://hintjens.com/blog:106: Standard practice (Pessimistic Merging, or PM) is to wait until CI is done, then do a code review, then test the patch on a branch, and then provide feedback to the author. The author can then fix the patch and the test/review cycle starts again. At this stage the maintainer can (and often does) make value judgments such as "I don't like how you do this" or "this doesn't fit with our project vision." In the worst case, patches can wait for weeks, or months, to be accepted. Or they are never accepted. Or, they are rejected with various excuses and argumentation. PM is how most projects work, and I believe most projects get it wrong. Let me start by listing the problems PM creates: It tells new contributors, "guilty until proven innocent," which is a negative message that creates negative emotions. Contributors who feel unwelcome will always look for alternatives. Driving away contributors is bad. Making slow, quiet enemies is worse. It gives maintainers power over new contributors, which many maintainers abuse. This abuse can be subconscious. Yet it is widespread. Maintainers inherently strive to remain important in their project. If they can keep out potential competitors by delaying and blocking their patches, they will. It opens the door to discrimination. One can argue, a project belongs to its maintainers, so they can choose who they want to work with. My response is: projects that are not aggressively inclusive will die, and deserve to die. It slows down the learning cycle. Innovation demands rapid experiment-failure-success cycles. Someone identifies a problem or inefficiency in a product. Someone proposes a fix. The fix is tested and works or fails. We have learned something new. The faster this cycle happens, the faster and more accurately the project can move. It gives outsiders the chance to troll the project. It is a simple as raising an objection to a new patch. "I don't like this code." Discussions over details can use up much more effort than writing code. It is far cheaper to attack a patch than to make one. These economics favor the trolls and punish the honest contributors. It puts the burden of work on individual contributors, which is ironic and sad for open source. We want to work together yet we're told to fix our work alone. Now let's see how this works when we use Optimistic Merge. To start with, understand that not all patches nor all contributors are the same. We see at least four main cases in our open source projects: Good contributors who know the rules and write excellent, perfect patches. Good contributors who make mistakes, and who write useful yet broken patches. Mediocre contributors who make patches that no-one notices or cares about. Trollish contributors who ignore the rules, and who write toxic patches. PM assumes all patches are toxic until proven good (4). Whereas in reality most patches tend to be useful, and worth improving (2). Let's see how each scenario works, with PM and OM: PM: depending on unspecified, arbitrary criteria, patch may be merged rapidly or slowly. At least sometimes, a good contributor will be left with bad feelings. OM: good contributors feel happy and appreciated, and continue to provide excellent patches until they are done using the project. PM: contributor retreats, fixes patch, comes back somewhat humiliated. OM: second contributor joins in to help first fix their patch. We get a short, happy patch party. New contributor now has a coach and friend in the project. PM: we get a flamewar and everyone wonders why the community is so hostile. OM: the mediocre contributor is largely ignored. If patch needs fixing, it'll happen rapidly. Contributor loses interest and eventually the patch is reverted. PM: we get a flamewar which troll wins by sheer force of argument. Community explodes in fight-or-flee emotions. Bad patches get pushed through. OM: existing contributor immediately reverts the patch. There is no discussion. Troll may try again, and eventually may be banned. Toxic patches remain in git history forever. In each case, OM has a better outcome than PM. In the majority case (patches that need further work), Optimistic Merge creates the conditions for mentoring and coaching. And indeed this is what we see in ZeroMQ projects, and is one of the reasons they are such fun to work on.

souprock 7y ago

He missed a big one: you have no way to stop Linux distributions from hacking up your software, and you'll suffer the consequences of whatever they do. I hit this with procps. (a package with ps, top, vmstat, free, kill...) It was horrifically demotivating, helping to end my involvement as the maintainer from roughly 1997 to 2007. (the other big issue was real life intruding, with me joining a start-up and having 5 kids) I had plans for command line option letters, carefully paying attention to compatibility with other UNIX-like systems, and then Red Hat would come along and patch their package to block my plans. They were changing the interface without even asking for a letter allocation. I was then sort of stuck. I could ignore them, but then my users would have all sorts of compatibility problems and Red Hat would likely keep patching in their own allocation. I could accept the allocation, letting Red Hat have control over my interface. Red Hat sometimes added major bugs. I'd get lots of complaints in my email. These would be a mystery until I figured out that the user had a buggy Red Hat change. Patches would often be hoarded by Linux distributions. I used to regularly download packages and open them up to look for new crazy patches. Sometimes I took the patches, sometimes I ignored the patches, and sometimes a wrote my own versions. What I could never do was reject patches. The upstream software maintainer has no ability to do that. The backlog of unresolved troubles of this sort kept growing, making me really miserable. Eventually I just gave up on trying to put out a new release. That was painful, since I'd written ps itself and being the maintainer had become part of my identity. Letting go was not easy. Maybe it had to happen at some point, since I now have more than twice as many kids, but I will be forever bitter about how Red Hat didn't give a damn about the maintainer relationship.

cyphar 7y ago
That sounds really awful, and it's really disheartening to see the (ex)maintainer of such a core piece of Linux distributions being treated that way. I work for a Linux distribution (SUSE) and I assure you that we don't all act this way. I've had to carry my fair share of downstream patches in openSUSE/SUSE packages, but I always make sure to submit the patches upstream in parallel. Quite a few people I know from Red Hat (and other distributions like Debian, Ubuntu, etc) do the same. It's possible that times have changed since then, or that it depends which package maintainers you are dealing with, but I hope it hasn't soured your opinion of all Linux distribution maintainers. One thing that is a constant problem is that users of distributions keep submitting bugs to upstream bug-trackers. If there was one thing I wish I could change about user behaviour, it would be this. Aside from the fact that the bug might be in a downstream patch (resulting in needless spam of upstream), package maintainers are also usually better bug reporters than users because they are more familiar with the project and probably are already upstream contributors.

burtonator 7y ago

I'm threading the needle in a project I've been working on which is both Open Source and has premium features around cloud sync: https://getpolarized.io/ https://getpolarized.io/ ... it's been interesting. I'm trying to give everyone the best of both worlds but since I'm catering to a large user base I have to make sure to keep everyone happy. Some people DO NOT want to do anything cloud. Some want their own cloud. Others want cloud and they want it easy. I think part of what I'm learning is that in order to get the trust from users I'm going to either have to be around for a long time or get the thumbs up from other organizations that can vouch for my positive intentions. For example, I want to write up a document about our commitment to Open Source but of course that takes work and I don't have a ton of time.

jakeogh 7y ago
Hey nice! I was not expecting to click that and get a working page without JS!
analognoise 7y ago
There was a pop-up that asked for money. The language of the bar at the top gives the impression the program will go away soon unless money comes in, plus the fact that someone was willing to inject pop-ups made it very difficult to trust - what if it goes commercial and someone is willing to inject ads or malware?

sheetjs 7y ago

We (https://sheetjs.com https://sheetjs.com) maintain some reasonably popular projects (our most popular, https://github.com/SheetJS/js-xlsx/ https://github.com/SheetJS/js-xlsx/, has over 15K stars and sees millions of downloads per month). It's important to remember why you are involved in open source. If those circumstances change, you should ask why you continue to remain involved. As soon as you lack a satisfactory answer, it's your cue to stop. Many large open source projects start out as a passion project or a solution to a specific problem that the original developers faced. Over time, other people face similar issues and rally around your solution and it is really easy to fall into the trap of bearing their burdens. This is a bad response. Other people using your open source offerings do not create any sort of obligation on your part to care or respond to their concerns. If someone really cares enough, they will incentivize your continued effort (like money or other considerations). It is unfortunately cultural taboo to ask some of the more vocal critics to pay, but setting up that dialogue at least shuts down most of the comments. IMHO the origin of most of these issues comes from the very thing that drives many people to open source in the first place: personal branding. If you remove your personal identity from the equation, it's a lot easier to "turn off notifications". Rants and criticisms are directed at this mystery character, not you personally. Since you are not personally tied to the project, working on open source feels like a distinct activity and is judged on its merits. You don't feel the same sense of obligations since you don't personally feel like you are disappointing the user base.

Sean-Der 7y ago
The sunk cost (maybe wrong term) is really tough. It is hard to walk away because you have put so much effort in. Especially if you don't have a company behind a project it will probably falter. I really enjoy Open Source 99.99% of the time. But that 0.01% I just remember how much work I put in.
chii 7y ago
> trap of bearing their burdens yep, don't bear other people's burdens without asking for money, or contributions (of labour - such as code)
ralphstodomingo 7y ago

Sean-Der 7y ago

I have only been doing Pion WebRTC(https://github.com/pion/webrtc https://github.com/pion/webrtc) for a year, but the hardest ones for me have been * Relationships tied to the project It sort of burned me out when the first contributors moved on. I have always been on the other side though, interests change or you change jobs. * Every user issue is urgent. It is hard figuring out what the most important thing to work on is. If a user takes time to file an issue it is causing them issues. I just have been on the other side and it doesn't feel great to be ignored. * Community members with different communication styles People aren't so much assholes, but just communicate differently. It is really hard to mediate, no one is at fault but I just hate seeing people leave/get burned out from it.

cerberusss 7y ago
As to hard figuring out what the most important thing to work on is: I have some code on Github and got a change request. I just replied that I can do it for my currently hourly rate. That makes priorities clear.
- Sean-Der 7y ago
  I don't want to bring money into it though. It personally makes me happy that is free of any financial pursuit. It is nice to suspend disbelief and just all work together on making things that make people happy :)
  - cerberusss 7y ago
    Yeah, sometimes money takes away the joy :)
imetatroll 7y ago
This is really nice. I wrote my own (probably bad) webrtc implementation for a personal project using gopherjs months ago. If I ever switch that project to webassembly, I will take a look at pion. Thanks for your efforts!

nerdbaggy 7y ago

I don’t know why so many open source users feel so entitled when they have done nothing for the project. I believe that anybody can help a project from code, documentation, financial, graphic design, etc.

MakeUsersWant 7y ago
Most projects don't actually want help. Go and try it: report a few bugs or point out usabilty issues. See what happens.
- thethirdone 7y ago
  Most of my bug reports have been very well accepted. The worst response I can remember is just not responding for like 3 months. And on the other side as a maintainer, any bug report that demonstrates a clear issue (crash, hang, etc) with a reproducible setup is appreciated. What can be really frustrating are bug reports that aren't bugs and a better understanding of the software would allow them to solve the problem. For example, there was one issue on Slic3r that was asking for a PDF output of config files. There is really no reason to do that.
- PeterisP 7y ago
  That's not really help that contributes to the project, that's communication or (often in the case of usability issues) opinion that might be useful, and even if it is, it just piles on more work on the project instead of helping with that work. Every project has accepted everything whenever I've actually tried to help with the actual work they're doing, i.e. solving a bug or submitting a pull request fixing some documentation, something that reduces their todo-list instead of adding to it.

bowmessage 7y ago

O/T, not meant to be rude, but under what moral framework do you find it reasonable to bring more than 10 children into this world?

cheschire 7y ago
I find that when people preface a statement with a negation, it has the opposite effect and draws focus to that aspect. "With all due respect," or "no offense but," or "not to be rude but..."
- sah2ed 7y ago
  That may be true, but I think the poster didn't frame their actual question charitably enough, causing the phatic expression prefacing the question to be rendered completely useless. IMHO, it was quite confrontational if you mentally leave it out: "... under what moral framework do you find it reasonable to bring more than 10 children into this world?"
deleted 7y ago
[deleted]
dang 7y ago
Please don't accost someone personally like this on HN. We detached this subthread from https://news.ycombinator.com/item?id=19936320 https://news.ycombinator.com/item?id=19936320 and marked it off-topic.

tlrobinson 7y ago

jonathanberger 7y ago
Unix. Email. TCP/IP. Just taking an initial stab.
- kbwt 7y ago
  All of those will be around not because they are good, but because so many other things are built against their interfaces.
  - aeorgnoieang 7y ago
    Ultimately, what else is 'good' other than being the foundation of further far-flung flourishing?
- gloflo 7y ago
  Those are standards and protocols, not software.
BillGates432 7y ago
Spider Solitaire
sanxiyn 7y ago
> And what's the oldest software that's still being used currently? I am very interested in this question, but much of software is proprietary and you don't have much visibility into their history. For software in the public, trivial lower bound is GCC 1.0 in 1987. Another case I know is Community Climate System Model, in continued development since 1983.

jondubois 7y ago

I've been maintaining my OSS project for almost 6 years. It's well used in the industry but nowhere near as popular as Redis. But I can relate to pretty much everything in the article even the thinking approach. It makes me think that it takes a certain personality to be an OSS developer.

austincheney 7y ago

I encountered most of the issues described so I set out to solve this problem. I did the horrible bad thing: I rewrote my projects from scratch. It took me about a year, pretty much all of 2018. I could afford to do this because I was separated from both work and family by military education and a military deployment immediately following. Now I have software that is stupid fast to extend and maintain. My software now executes faster than comparable applications coming out of Facebook with more options and at a very tiny size after accounting for dependcies. Now I finally have time to watch all the shows I have missed and play games since my software has fewer defects compared to similar applications and is faster to patch. I did get tired of the asshole factor though and even deleted my Reddit account as a result. Now it’s harder to promote my software online but deleting my reddit account again opened up more personal time.

monksy 7y ago

It sounds like this is similar to the harassment that he received over redis using the terms "master"/"slave". (Even DHH jumped in and used his platform to harass) http://antirez.com/news/122 http://antirez.com/news/122 For someone that is giving parts of their life to help others, the amount of entitlement that people expect is unbelievable.

stupidcar 7y ago

It's ironic that Git was intentionally designed to decentralise the process of software development, so that there was no single "blessed" repository, but instead of a network of peers, each of which could evolve at a different rate and in a different way, with the community deciding which would "win" in terms of popularity. And yet, via Github, the community has reinvented the centralised model of software development. For any project, there is a single instance that is the "blessed" version, by virtue of having the most stars or collaborators, or owning the associated package name. 99% of forks are nothing more than a place where you create a feature branch that you intend to PR to the blessed project. I hope that, one day, somebody invents a git-based project ecosystem that solves the problem of decentralised project management. I don't know exactly what this would look like, but I think it would need to embed the idea of community and contributor consensus and democracy at a fundamental level, separating the concept of the project and project ownership from any individual fork.

djangovm 7y ago
i am wondering this probably because of two factors: 1. accountability: where do I go looking if something is broken? 2. and discoverability: where to search, and whom to believe as being the correct owner of the copy of the codebase. this is similar to block-chain currency (based on my limited understanding.. correct me if i am wrong). While it is meant to be decentralised, entities like coinbase effectively create a central entry/exit point somewhere in the ecosystem.
- dzmien 7y ago
  I immediately thought of Bitcoin when reading the OP. It can, and has been "hard" forked via miner consensus. That is, of course, one level removed from git, but I guess git"hub" could be more like gittorrent or something where instead of hosting a repo on one central server, the repo is hosted by a swarm and the version with the most seeds is the winner.
albertzeyer 7y ago
But it does help for decentralized development, or not? And you have this single instance of authority in almost all cases? E.g. for Linux itself, you also have that, and Git was developed for Linux. I think the issue is more about how to structure pull requests, issues, etc., in a better way (maybe hierarchical), such that this matches the exponential number of more communication. GitHub does not help too much with this, but it also does not really fight against this. This is basically a problem every big project has to manage in some way. For comparison, I would look at other big projects like TensorFlow, Firefox, Chromium, Linux, CPython, etc.

bluehatbrit 7y ago

For those struggling to access the site: https://archive.fo/10IpE https://archive.fo/10IpE

bmh 7y ago

It seems like there's an opportunity for a tool to help solve this (ie something other than GitHub issues).

aeorgnoieang 7y ago
I'm sure different tools could help somewhat but ultimately anything replacing GitHub issues would still involve some kind of social, i.e. communication, structure and that's just a hard thing to build and maintain.

dullgiulio 7y ago

Salvatore's feeling that he should be thinking about big ideas makes me think of Fabrice Bellard. He drops amazing things, let's the community manage them and concentrates on starting the next amazing thing. Maybe that's something good for Salvatore too.

marknadal 7y ago

So very true! I also maintain 10,000+ GitHub starred OSS database (https://github.com/amark/gun https://github.com/amark/gun), and can relate to a lot of these points. Worse than the jerks, though, are the bike-shedders. It is emotionally much easier to confront jerks, even though it is hurtful. But the people who "Why isn't this written in X language?" or "Here's a PR to turn tabs into spaces" are honestly well-intended but naive and short-sighted. Explaining to those people why you have to reject their PR because it provides no additional value and is purely an arbitrary distraction takes quite a bit of time trying to be delicate, but is nearly as much waste of time.

dbnotabb 7y ago

We're working to address some of the issues raised in this piece, by creating a new way of working on Open Source. Companies post their issues on our platform and contributors are incentivised by getting to know a company, a monetary reward and the potential of raising their profile with the company to get hired. We're looking for feedback so if anyone has any thoughts - https://works-hub.com/issues https://works-hub.com/issues

Crinus 7y ago
Others have tried what you seem to be trying and didn't work, how are you going to convince people who decide to use tech because it is free, to pay for it and pay for more than insultingly low scraps? And once someone does accept and the work is done, what happens if they are not the main developer of the software that was worked on and the developers decide they do not want to accept the work? Where does that leave your customers who most likely (especially if their initial major motivation was free stuff) wont want to pay someone fix/update the patches every time a new version is released nor be willing to have their own fork? I might be missing something of course since your site doesn't work. Every time i tried to click on a link nothing happened. Firefox's dev console had this warning: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.segment.io/v1/p https://api.segment.io/v1/p. Looks like your tracking is broken. BTW, i'm kinda curious, how come you have "25,000+ software engineers on WorksHub" but only 8 issues, all of them from your own company?

makecheck 7y ago

People seem to have a serious lack of understanding when making requests of others. - When you send an E-mail, at least imagine that the recipient may have literally hundreds of other messages to dredge through and the time required to respond (and detail of response) may reflect that. Not personal, don’t get mad at them. - When you send an “instant message”, it may be instant for you but for all you know the recipient is deep in the middle of something and won’t respond for awhile. Not personal, don’t get mad at them. - The recipient may be on the other side of the planet. Err on the side of extra information so you don’t wait days for a response that just has to ask you for more. - When you file a bug, “thank you but do some homework”. A person dealing with 1000 other things will not have time to hand-hold you through all the things you’re not telling them yet. Be precise and complete. Be reasonable about when/if to expect a fix. - And for that matter, in retail, or traffic, or 100 other things in life, you don’t know as much as you think you do about what other people are dealing with. Stop for a second. Imagine their situation. That person not instantly serving you and only you has a dozen other things going on.

gppk 7y ago
I agree with a lot of these. One thing i've noticed in life is that our use of aschynchronous communication methods is much more in a "respond now" fashion. Also as a contributor to StackOverflow your point about asking questions with the right amount of information is really spot on.
senorjazz 7y ago
> - When you send an “instant message”, it may be instant for you but for all you know the recipient is deep in the middle of something and won’t respond for awhile. Not personal, don’t get mad at them. People don't get it. If they said a DM / IM or any program which is considered a "chat" app they expect instant replies. I run a single person software company. I used to allow people to contact me for support any and all chat programs. So for paying customers you can magnify that "expect an instant reply" factor. People would get quite annoyed, regardless of whether it was Sunday, or 3am in the morning for me. For that reason, only email and forum support is no offered. Never had a complaint since about wait times. People expect to wait after sending an email. They expect to wait for a forum post. They do not expect to wait for a chat / IM / DM response.

sdegutis 7y ago

> Moreover I’m sure I’m doing less than I could because of that, but this is how things work. It doesn't have to be. What if all the people who "pay" for Redis, their money want into a collection bucket, and nobody got the money until they earned it. Then you work on your own schedule and "earn" that money at a fixed dollar rate per hour, and claim the money at the end. Other trusted contributors can join this effort and claim the money after working the hours. This way, hours are up to the contributors, and money is more like the "pledge" in Kickstarter for example, or a check that's not yet cashed.

jancsika 7y ago

This is a vicious cycle of a mentoring problem. If the maintainer never learned and practiced "role shifting" as a part of the developer process, they are going to have a bad time if the project gains any traction whatsoever. Worse, there's no easy way for a mentor to swoop in and teach them basic role shifting tactics. Because such an attempt would likely be interpreted as just a user giving yet another uninformed opinion. Edit: And such a maintainer is unlikely to be able to delegate to newcomers since mentoring isn't part of their skillset. (Thus the vicious cycle.)

adam1210 7y ago

I have a small (2k+ stars) niche game-related project. The hardest part for me is saying "no". If someone proposes a change that I think is out of scope, or is not something I want to maintain (maybe the introduced complexity is greater than the benefit of the feature) I find it difficult to explain that in a way people understand. Often times people get offended by it and then become angry at me, and over time it becomes very draining.

nicpottier 7y ago

> Sometimes I believe that software, while great, will never be huge like writing a book that will survive for centuries. Note because it is not as great per-se, but because as a side effect it is also useful… and will be replaced when something more useful is around. I once saw a sig somewhere that was something along the lines of the author's goal being of writing some piece of software that would outlive them. That seemed like a neat, but incredibly ambitious goal, very very few pieces of software will meet it. That said, Redis is probably one of them. It isn't too hard to imagine that there will be Redis instances running somewhere in 40 years, and though I wish antirez a long life, I think it is likely there will still be Redis instances chugging along after he passes. So be proud antirez! You've most certainly made a dent in the universe.

redisman 7y ago
Data migration is difficult. I'm sure there are a lot of very old databases still chugging along in some dusty office corner because no one wants to touch them since they've worked adequately for the last 30 years.

mamcx 7y ago

I don't remember if I get the idea elsewhere or what, but: "Worse than a failed project/business, is a successfully one" I part of "small scale" projects and one thing that some fear, very much, if that the project GET traction. This have killed some business before.

ilaksh 7y ago

I guess I will be the one to complain about something that makes me look bad. Since no one else complains about this, it makes me think I might be the only one. However I doubt that. The problem I have had with my open source projects so far is that most of them seem to not be very popular and they receive very little if any feedback at all. It's gotten to the point where I feel like popularity and merit are not even directly related. It seems like maybe part of it is tied to some kind of social networking popularity contest. Certainly I have to think that way otherwise I would never try to contribute anything again.

narnianal 7y ago

The best thing creators should do in my eyes, and I always do it myself, is trying to make yourself jobless. Solve that problem, find people who are good at maintaining stuff, move on to the next problem. You don't need to sit there looking through bugs 12 hours a day. In fact there are people who love this continuous struggle more than you, and who therefore also have developed skills at handling these situations without having sleepless nights. Find these people once your project reaches a stable point from a creative POV. Then help these people get started, not the users. Then you will see that you need to do less and less. And when you are at about 30% load start using your time to find the next problem that you can solve. No reason to be ashamed of either. There are loads of people who really love this continous lifestyle and there are few people who actually love finding a new solution to a problem that nobody can solve. Everybody will be more happy in the end, even the users. PS: You can also see it in a different way. There's not just jenkins and github and AWS to setup as a system to get your project running. People are also part of the system. People who move the issues along these pipelines. There is no system if people aren't part of it. And there are not just devs and users, there are also maintainers, communicators etc.

2easy 7y ago

Really great article bows down