12 ms·
My condolences, you’re now the maintainer of a popular open source project
- fagnerbrack 10y agoYeah, just how I feel, see http://github.com/impress/impress.js http://github.com/impress/impress.js and https://github.com/impress/impress.js/issues/435 https://github.com/impress/impress.js/issues/435. Luckily the activity doesn't match a number of stars, although still, it is on the top 30 on Github.
- jordigh 10y agoThis seems like a perfectly reasonable issue? I think if someone is unable or unwilling to spend time maintaining a project, designating a successor is the right thing to do. Or are you saying that we shouldn't even have to ask the maintainer to designate a successor, we should just find one without the maintainer's involvement?
- bllguo 10y agoI don't entirely understand what the commenter is trying to say, but from his username it seems like he is the successor.
- fagnerbrack 10y ago> but from his username it seems like he is the successor That's correct, I thought it was obvious but I was trying to say that if more experienced people did this the open source ecosystem would be in a much better state.
- lyra1337 10y agoi can count 16 wp-cli
- smegel 10y ago> Open source produces quantitatively better software As someone who mainly uses open source software for most of my work, I'm not so sure about this.
- scardine 10y agoAs someone who have to deal with crappy proprietary software for some of my work, all I can say is that with open source at least I can fix a problem or implement a feature that is lacking - instead of bang my head on the wall waiting for the good will of the vendor (even when I want to pay well for a hotfix).
- maze-le 10y agoI (and I think we all) have worked with crappy open source and good proprietary, as well as good open source and unusable proprietary software. But one thing you said stays true: "at least I can fix a problem or implement a feature that is lacking". And I think that is the main reason people stick to open source.
- mamon 10y agoAnd I think that it's the main reason why some open source projects remain so crappy: main contributors are mostly interested in development of cool new features and users are treated as both beta-testers and maintainters, and are expected to find and fix bugs themselves.
- spriggan3 10y ago> And I think that it's the main reason why some open source projects remain so crappy: main contributors are mostly interested in development of cool new features and users are treated as both beta-testers and maintainters, and are expected to find and fix bugs themselves. If these projects were crappy no one would bother using them. You're not entitled to anything as a user of open source software. Open source is about collaboration, not entitlement,it's not one dev having to maintain everything for other developers.
- ashitlerferad 10y agoHmm, neither of those definitions of "open source" appear to be correct. Great post otherwise.
- kmfrk 10y agoIs there a good reason GitHub doesn't support (issue) "moderator" roles instead of "contributors", which also gives write access? So much could be solved with better moderation tools.
- rincebrain 10y agoThe only reason I can see is that Github doesn't have any notion of users that are not developers.
- impostervt 10y agoI'm the creator of a just-mildly popular OS project (~700 stars on GH) and I had to give up being the main maintainer. Too many "issues" were just people who couldn't debug their own code, or "issues" where the person would describe some weird edge case but be unable to provide any example code. After enough of those, and getting busy with other things, I just couldn't keep up with it. Luckily, one of the contributors stepped up and is now the main maintainer. I still read through the issues that come in and he does a great job of responding and keeping cool. I don't know how he does it.
- akerro 10y agoI was contributing to more popular projects, between 2.5k to 4k stars on GH, I just gave up and stopped doing it for free when users just open issues like 'I requested this feature 5 months ago and it's still not implemented. what are you waiting for?', after reading 8th of such issues in 3 projects I just left all of them the same day and started working on my commercial project. Working on OSS where every idiot can open an issue for free and complain or think we're their slaves if waste of time and energy. Never. again. The worst were users or forkers who asked me to change license of a project from MIT to GPL because they would like it more... eh.
- stuaxo 10y agoCan always close as WONTFIX - reopen if you have a pull request in the first case ... and just WONTFIX the license changers.
- akerro 10y agoDid it once. Closed an issue I couldn't reproduce and author didn't want to show me their code. I got blamed for not helping them and not fixing problems in my code :) I stopped responding to such issues at all.
- jbrooksuk 10y agoI maintain Cachet [1] which has 4.4k stars on it. I've closed several issues in a similar vein, only to be ranted at for not giving a reason. I shouldn't have to explain the same reason for the fifth time when you could've searched for it already — but hey, I appreciate the thoughts. [1] https://github.com/Cachethq/Cachet https://github.com/Cachethq/Cachet
- sotojuan 10y agoMany have started adding collaborator status to any user that makes a non-trivial commit to both show appreciation and lighten the load.
- akerro 10y agoSo they are also able to push directly to master, push bad changes, backdoor/add malware to your projects and make a release. I would be careful with this.
- diggan 10y agoI'm one of the people who do this, if anyone is doing more significant change than just updating the readme/fixing a typo, give them collaborator status after checking out their profile. I think the benefit of people feeling proud of being a collaborator and trust from me, is bigger than the risk of someone ruining their own reputation by adding a backdoor. But, most of my projects are tiny-ish and not even close to big, so I guess I have a bit more flexibility in this. EDIT: Just remembered that you can activate "Protected Branches" on Github (and I'm sure something similar exists for Bitbucket and Gitlab as well) that disables pushes straight to master.
- lmm 10y agoThey can't make a release without the signing keys. (Well, they can, but everyone will know it wasn't one of mine)
- sotojuan 10y agoIt's all about trust. So far no one I know has been burned.
- mrob 10y agoYou're not just trusting them to have good intentions, you're also trusting them to keep their system secure. If you have commit access to a popular project then your commit credentials are a high value target. What do you know about their security practices?
- j_s 10y ago
- jordigh 10y agoA lot of those 80% projects on github without licenses are simply not meant for public consumption. Think things like bash or emacs dotfiles or class notes scribbled into a txt file or a very personal project that has no hope of working anywhere but on the author's machine. I think people overstate how "post-licensing" people view open source (née free software). For everything important, people still mostly slap free licenses on their projects.
- isxek 10y ago...which is probably why it's a better idea to keep those projects in private repositories outside of Github. Yet somehow, people keep forgetting there are other project hosting options (Bitbucket, Gitlab, etc.).
- nathan_long 10y ago> which is probably why it's a better idea to keep those projects in private repositories Not necessarily. Public dotfiles are easy to link to in conversation, and "users" are likely to be people who just copy and paste some interesting lines. A license is probably irrelevant for, eg, vim configuration options.
- kzisme 10y agoAnother presentation that is in line with the thoughts of this discussion: https://www.youtube.com/watch?v=UIDb6VBO9os https://www.youtube.com/watch?v=UIDb6VBO9os
- jordigh 10y agoThe most important thing about releasing free software (open source) is that you don't owe anything to anyone by doing so. Virtually all free licenses actually codify this. If you read the SHOUTY CAPS part, it says exactly that: no responsibility from the author. People can come and ask for you to fix something or support them or accept their patches. That's fine, and if you want to engage them, you can. But there is no obligation to do so. Once I accepted this, the growing pile of bugs/issues/support requests on the Octave and Mercurial bug trackers become a lot less anxiety-inducing. I'll try to help, but if I couldn't... sorry, it's not my responsibility!
- andy_ppp 10y agoThere needs to be a filtering of issues down to maintainers. Github should think about how to build this IMO, it would make things much better if there were levels of involvement: -1) Asked for help before and NOT valid -1) Pull request not valid -1) Noisey user (might have positive Karma but often creates irrelevant issues). 0) Not asked before 1) Asked before and valid 2) Asked before and committed fix 3) Pull request valid 4) Pull request merge 5) Complex feature merged 6) Contributor 7) Maintainer Now each of these can be discussed how to get there but if you could by default only see one level above and 3 levels below that would help a lot. The default count of issues and view of maintainers/contributors on github should not include anything below level 1.
- mcguire 10y agoYou're bringing back memories. I was an AIX sysadmin (among other things) when IBM added a new layer of tech support because too many issues were making it through to the developers. You had the script readers, someone to read the man page to you, then the new layer, that I never reached because I don't like yelling and we only had 8 servers. Then, I think, you got to someone who could triage issues.
- andy_ppp 10y ago>>> someone to read the man page to you If it's in the docs/easily googleable could be another minus.
- Chris2048 10y agoperhaps a triage where other users can vouch for or 'bump' new issues?
- ManlyBread 10y agoQuestion: why people seem to be so affected by unpleasant contributors? I mean, no one forces these people to use an open source project and no one has an obligation to support it at all, yet I see articles like this popping up pretty often. What's the harm in ignoring the unpleasant contributors and focusing on the ones that provide actual value to the project?
- zelos 10y agoIt's hard to block them out. You can tell yourself to ignore them, but (in my minimal experience at least) it's near impossible to actually do so completely.
- beachstartup 10y agobecause after working all day it takes a mental toll to read and process some idiot lashing out at you for their own intellectual shortcomings.
- Ocerge 10y agoIn the end we're all human. You can try to ignore it, but just scanning the text is probably enough to raise the blood pressure of most people, even if you immediately block the offender. You still read it and it was still stressful.
- x0x0 10y agoBecause you get a stream of rude, entitled, hostile people either directly emailing you or pushing notifications into your email. All for a bunch of unpaid work.
- shados 10y agoIt gets really hard sometimes. Take the following issue as an example: https://github.com/reactjs/redux/issues/1528 https://github.com/reactjs/redux/issues/1528 Later in the issue, someone jumps in the discussion and trashed all over everyone. That same person hopped on every blog post, ever medium post, every discussion, gitter, everything. It was bordering on harassment. I don't maintain that project so it's easy for me to ignore, but for the people involved, it must have been pretty rough.
- Jedd 10y agoThis is one of those articles that reminds you why we should prefer the term 'free software'. > First, a conclusion from the 2015 Future of Open Source survey: > “Seventy-eight percent of respondents said their companies run > part or all of its operations on OSS and 66 percent said their > company creates software for customers built on open source. This > statistic has nearly doubled since 2010.” The 2015 survey on this website was responded to by 1500 people. (0.0000002% of the population) They don't provide numbers for the 2010 response set. > Second, Nadia Eghbal, who is doing really great research into > the economics of open source, calculated that “open source was > worth at least $143M of Instagram’s $1B acquisition.” Likely wrong, but my feeling is most HN readers aren't thinking Instagram valuation is the best way to judge the value of free software. > I think there are a few reasons for this Cambrian explosion of > open source usage: > > 1. Open source is free to use, which means a company can spend money > on people (aka innovation) instead of software licenses. Everything I've read in the past 15 years suggests that free software's value proposition isn't founded on capex (in fact it's probably misleading to look at these numbers) > 2. There are now a critical mass of reliable open source > components, which accelerates your product’s time to market. Assertions without evidence. Plus a lot of us probably have thought a critical mass was achieved a long time ago. > 3. Open source produces quantitatively better software. Assertions without evidence, despite popularity of opinion. > 4. Near and dear to me personally, open source permits > companies to collaborate on common problems without > complicated business agreements. In my experience some of the most exhaustingly complicated licence discussions have been around the various free (or similar) licences on various lumps of code. At least with non-free licenced code you know nearly precisely where you stand. > "Open source" now means two things. > > Clearly, there’s the official definition, a permissive > license which grants certain freedoms to the end user. Clearly? No citation provided. Worse yet, 'open source' was clearly a rebellion by esr against the idea of emphasising the freedoms to the end user. Eric's related rant at http://www.catb.org/esr/open-source.html http://www.catb.org/esr/open-source.html is often provided ... but read it critically and you realise there's very little of substance there, other than negating the extant 'free software' position, and a call to authority fallacy. > But when people use "open source" today, they’re probably > referring to building and collaborating in public. In fact, > they may not care about the license at all — over 80% of > projects on Github don’t have an explicit license. 80% of github projects don't include a licence ... qed ... 'open source' equates to building and collaborating in public? > Why are so many people involved in open source? Well, for > all of the business reasons covered before. I also think it’s > joyful to get to work with people of a variety of cultures > and backgrounds. Additionally, open source has given me a > sense of permanence to my career, where the job I’ve taken > from year to year has not. I'm empathetic, but this sounds like a plea for help. More importantly it precludes the more common, and nuanced, reasons that people generally provide for why they spend so much time and energy contributing to the free software movement. The rest of the post feels a bit facebooky, with lots of 3-8 word pithy aphorisms encoded in a 1024x576 pixel image.
- Keyframe 10y agoI salute you, open source maintainers. You are our heroes we don't deserve. I'm pretty sure I would become a murderer if I had to deal with what you deal with on a daily basis.
- deleted 10y ago[deleted]
- franciscop 10y agoI discovered another way of getting contributors with Umbrella JS [1] (500+ stars), using up-for-grabs [2][3]. In total I'd say it's similar or even a bit more of effort per issue, however many people contribute and sometimes they step up and continue with more things. Not sure how useful it is for projects that are more monolithic though, I was lucky with this one as Umbrella JS has many small modular parts. [1] http://umbrellajs.com/ http://umbrellajs.com/ [2] http://up-for-grabs.net/ http://up-for-grabs.net/ [3] https://github.com/umbrellajs/umbrella/issues?q=is%3Aissue+label%3Aup-for-grabs+is%3Aclosed https://github.com/umbrellajs/umbrella/issues?q=is%3Aissue+l...
- orionblastar 10y agoThere are a lot of beginners who try to learn programming by using GH. They might not know how to make an example, or how to reproduce the bug by giving directions. When I worked as a programmer, I had coworkers and other employees I worked with who couldn't tell me how to reproduce a bug, or give example code, and I had to train some other programmers in the language to help them learn more to work with a team. You can't just WONTFIC an issue, and yes it is harder to work that way. You cannot block or ban people who are annoying or ignorant in a corporate environment. You have to find a way to help them out, by educating them, or just trying to fix the bug as best you can even if you can't reproduce it. I made a debug version of the program that trapped for errors, and wrote them to a log file and displayed a custom error message so I can tell what part of the program it had the error in. You have to learn how to innovate and work with annoying and difficult people who don't even know they are annoying or difficult. Yeah it is stressful, but that is the difference between an open source project on Github, and working for an employer as an employee or contractor.
- deleted 10y ago[deleted]
- makecheck 10y agoThis could also be viewed as a challenge to develop better tools. For instance, maybe there is data mining to be done on issues to auto-aggregate them so that you can still make some sense of the list without manual tagging and without relying on each submitter to choose sensible categories. Maybe there need to be open-source libraries aimed at unclogging issue systems, such as a system for in-app bug reporting. Maybe issue-tracking systems should auto-upgrade priorities on stale issues, or auto-close them based on lack of activity from the submitter.
- nicolasMLV 10y agoLet's hope Github will find a way for users to be able to 'tip' maintainers. I concede it is very hard to find the solution (Who? When? How much?)
- fudged71 10y agoI assume this is already possible with ChangeTip. I don't think it would ever be built in as a feature. There is also Patreon. I have seen people fund project maintainers this way. Enough for a full income https://www.patreon.com/foosel https://www.patreon.com/foosel
- cyphar 10y agoCan we please stop using the term "open source" when referring to free software? Especially in the discussion of benefits of free software over proprietary software. What you're contrasting here is the bazaar model over the cathedral model (though the book itself is horrible).
- tropo 10y agoDealing with users is nothing compared to dealing with Linux distributions. The distribution will patch your code. You are powerless to stop this. They will add bugs. They will add ill-conceived and/or incompatible features that the users will come to rely on. Fedora adds a -Z option, and Debian adds a -Z option, and SuSE does too, and all of them are in conflict with each other and with the purpose for which you had reserved the -Z option. Of course, the users will blame you.