I once wrote a library in backbone.js to have a data-synchronized list. It allowed me to provide an array, and it'll keep that array sync'd up to what I saw.<p>I had a kid and a fulltime job and going through a divorce. I happened to use it at my job, but everyone kept asking for me to integrate it into new up and coming repos which I didn't have time for. Honestly I felt bad about not caring, but the reality is that I didn't. I had other things on my mind.<p>Some people are DINKs (dual income, no kids) and get bored so instead of video games they'll make a side project. Some people have totally other circumstances. For me I wanted my spare time to either zone out to some games, or zone in to spending time with my daughter. I had plenty of coding to do at work.
I agree: it is OK for your open source library to be a bit shitty. However, it also can simultaneously be not OK for you to publish it in a package directory with a generic name and a description talking about how awesome it is as a trap for other people to run into, and that is really the core problem: it isn't that you didn't spend an unreasonable amount of time and money to make a good product that no one paid for (though I do know--all too well, as the sole maintainer of some key projects for a sometimes ungrateful ecosystem--that there are many people who really are just looking to be assholes), it is more often that you overhyped a side project and then put it somewhere obvious for other people to find it, only for them to discover that it was "a bit shitty" long after they deployed it; and sure: it is totally their fault for deploying something without carefully reading your code to figure out that it was a bit shitty beforehand... but should they really have to do that? When you release code that you don't intend to back up with a ton of time and resources, please do the rest of us a favor and use a name that no one is going to mistake for a standard package, put a note on it that says "this is a side project" so expectations are clear, don't write a readme file in the past tense about features you hope to one day implement, or, if you just can't bring yourself to be responsible like this, maybe just reconsider whether you need to publish it at all, as it actually doesn't <i>necessarily</i> make the world a better place <i>just</i> because it is open source. Seriously: if you bring something that you know tastes bad or will make someone sick to the potluck and put a little sign on it saying "gourmet enchiladas: much better than what you get at the store" and put it in the center of the table, it is still a problem <i>even though</i> "it is ok for you to not really know how to cook or not have that much time and participate in the potluck anyway".
I've used and been the maintainer of a "shitty" open source window manager off and on for the last 10 years.<p>I love the project. People at my last few companies joke about it. But it's so fun.<p>Who cares if it's shitty. Ride bikes and write code.
I had a GitHub project that got a few hundred stars. The amount of mean, crazy, and entitled people is crazy. I have no idea how the bigger projects can deal with it.
I agree with this to the extent that "open source your library" means "publish it on Github". Adding it into a package management system, be it one for a language or one for a Linux distro, is implying some level of stability and functionality. This is especially true if you choose a desirable namespace for your project on a system that doesn't differentiate by username.<p>Essentially; do publish all work you possibly can, simply be clear about what the software does or does not do.<p>I am very guilty of not doing this myself. I throw together some bit of code that is useful to me, and dump it on github with no explanation of what it does or how to use it.<p>As a bad example, I'd encourage everyone like me to put in a bit of effort to explain what your code does, so that when someone stumbles across it they have a way to give it a try and see it doing something.
Github can help with this situation a lot. Yes, people are free to write and abandon whatever they want, but once a library has had hundreds of dependent users, and the primary repo is abandoned / unmaintained, Github could do a lot to guide dependent users away to a better fork.<p>Today though, every popular repo has hundreds of forks and there is no easy way to identify forks that are more actively maintained. I understand it is a non-trivial problem, but hopefully Github has the talent to solve this problem.<p>At the very least they can make it easy to ignore forks where<p>1. changes have already been merged upline
2. forks that only have cosmetic changes of imports (happens a lot for Go repositories)<p>This will allow the developer to pass the torch, so to speak, to someone else willing to maintain their own fork.
I wrote a Python library that was pretty popular at one time. I gave a talk on it at PyCon, at one point it was in the top 200 most downloaded packages on PyPI.<p>Since my employer told me I was no longer allowed to work on it at work, I have felt quite a lot of guilt about all but abandoning fixing bugs and reading the mailing list. I've been working on a "next generation" version, almost a rewrite, but I don't see a clear path for releasing it in a way that helps people still using the current version.<p>It may be self-serving, but I am really going to try to take this essay to heart, and not beat myself up everytime a weekend goes by that I don't spend working on my project.
I have an OSS 'fun project' - I'm still amazed by the number of issues/emails I get raised which say:<p>"You should rewrite in" / "Why does't it do" / "Make it do".<p>It's nice that people are using it. I generally (try to) assume this is a language/cultural thing, and people don't realise that they're coming across as a bit rude <i>in English</i>.<p>But, it would be nicer if people approached commenting on OSS by first thinking "Author is doing this for fun, unpaid, and I'm getting something nice out of his/her time", THEN writing their comment.<p>I'd get the same issues raised, and that's fine. But the language might read a bit nicer.
But when potential employers come looking at your work they'll say "hey this code is shitty! It's not a work of art with 100% code coverage tests and perfect in every way. We can't possibly give you a job. Every line of code in our corporate repo is Mona Lisa quality, we can't let rubbishy developers like you in."
I have never contributed to open source because I have always been so impressed with the source code I’ve seen in these projects. It intimidates me! I’m a self-taught programmer, and while I’ve certainly written thousands of lines of useful code (useful to me, in any case), I know it isn’t “correct” (as in, idiomatic or ideally what you should write). If I could ever get to the place where I trusted my own work, I’d love to contribute to open source because I do have a few projects in mind (mainly useful to folks in the humanities) that I know I can make, but I’m just too embarrassed at the low quality/ugliness of my code.
As both an open source author/producer and consumer, I wish more projects were forthright about:<p>0) known defects<p>1) when the author no longer uses the library themselves<p>2) the repo is abandoned and alternatives are not given<p>There's a <i>lot</i> of abandoned code out there. It'd be nice if package managers had abandoned-package detection built-in.
I just picked up maintainership of django-address. It is a set of models and methods for dealing with postal addresses in Django.<p>The product is dominant in seo and many django beginners and intermediate install it without looking at it.<p>But it has also languished for years and failed to get an important model rearchitecture after the author had to stop work on it.<p>Still, I see it as a great turnaround opportunity and I’ve already learned a lot about OS and the pressure of knowing people want code fixed.<p>I think this article is for the author, Luke, who made this for himself for Australian addresses when django was still a smaller framework.<p>But it is also for me as someone trying to get context on how it has languished so long, and motivation to steer this thing into a place where it into helping more people without undue pressure.
I've a little anecdote on this. Once at a community potluck, our table ended up with several wine bottles...but no corkscrew. I reasonably asked a neighboring table to borrow one of their own (nice ppl, but strangers). Well, nicely, they lent me some suspiciously plasticky version of a corkscrew, literally, the screw was made of some sort of plastic!). Shitty, in one word... Sure enough it snapped, the cork still stuck, I'm embarassed, offered the owner another wine bottle in apology. Had a laugh about it together and fun time. But it was a lesson on shittiness-in-disguise-of-utility.<p>Similarly with an open source libs or utils. If it's shitty by your own admission, then either keep it to one-self or properly warn people that it's just that ... shitty, not MIT kind of AS-IS.
I used to maintain a bunch of open source libs but stopped because I felt the expectations from users were unrealistic for something that was not my full time job. Open source is great but I wouldn't do it again unless maintenance was my top focus.
I maintain an open source project with ~2k stars (<a href="https://github.com/kyleconroy/sqlc" rel="nofollow">https://github.com/kyleconroy/sqlc</a>). There’s a large list of bug reports and feature requests, but since I don’t work on it full time, I’ve gotten really good at saying “No” and “I’m sorry”.
A dilemma that we are running into at work is that we have all our software open source and readily available on github but use an internal bug tracker to manage bugs picked up by QE and other people in our org. These bugs are given significantly higher priority than our GH issues and we end up with a pile of GH issues that no one has the time or ability to adequately track. As our team recently set up its own open source working group and generally is making open source contributions in other projects a higher priority I see this problem getting worse. Does anyone have any suggestions how to overcome such an issue?<p>And I guess I'd just like to add my two cents: sometimes your issues are not being adequately triaged because the project is using another system for bug tracking and the engineers are slammed fixing those bugs instead lol.
I've initiated 2 OSS libraries that are major libraries in their fields (hyperscan and simdjson), although neither were things that I have done the majority - or even all that much - day-to-day coding on. I totally agree with the 'bit shitty' aspect.<p>This comes down to releasing an MVP so you can find out what people want and iterate. If your project is actually viable and interesting to people, you'll get a lot of useful feedback a <i>lot</i> quicker than you would if you sat around "perfecting" it.<p>A big point: there's an anecdote about a Hungarian economist who, when asked "how are you?" would reply "compared to what?". Sometimes a 'shitty' library is only 'shitty' in your head compared to some idealized picture of what 'good' might be. We had commercial success with Hyperscan (back when it was a closed-source library) when it was in a state that was Truly Shitty as compared to how it is now (actually, even a couple years later it was much better). However, the question "compared to what?" was important - it was way better than anything else that solved the same problem (including custom regex hardware). So we made a good chunk of money with a "shitty" library.<p>It's important to be honest about what your answer to "compared to what?" is, the state your library is in, and how much work you plan to do, though. I'm not crazy about the temper tantrums people throw about this ("how dare you TRICK me into using your free library") but it would be nicer if people were to use 0.1-type version numbers and words/phrases like "experimental" or "hobby" or "I wrote this for a lark" a bit more freely.<p>If you're planning to win in some 'niche', please make that clear - Hyperscan was the best available multi-pattern streaming regex matcher at the time, but it would have been a <i>dreadful</i> substitute for libpcre if you wanted a featureful single-pattern non-streaming regex implementation.
Just a FYI for the library authors out there, but you can usually set a template for submitting bug reports and issues (for instance, Github has this feature). This can help put a message in front of users right as they are making the issue. It might not fully alleviate the issue, but it might help set expectations! (i.e. "Please feel free to submit a bug report, but please note we are volunteers. We cannot get to every issue, and we can more easily resolve issues that are well researched before making it here.")
From the article:<p>> There is no obligation to free labour. Every hour you put in working on your project for free is a gift to the world. If the world comes back to you and says "You are a bad person for not supporting this thing I need you to support" then fuck them. If they want that they should pay you for it, or do it themselves.<p>I've had my Javascript canvas library "side project" on GitHub for seven years. In those 7 years I've had exactly ONE issue opened - which then got closed when the person who raised it worked out for themselves how to solve the problem they'd encountered.<p>Instead, people email me their questions - maybe a dozen of those over the years. They're usually really simple questions on how to do this or that using the library. I ask people to open an issue on GitHub for their question (because other people might find whatever answer I come up with useful) ... then I never hear from them again. I like to assume they solved the issue for themselves and don't need my help; others may choose to interpret the facts differently.<p>So I'd actually welcome people raising issues. It shows me that my "side project" is more than vanity, that people find it useful. And it would help improve the library because I can't think of every use-case or edge-case myself.<p>... But whatever happens, I'll still continue working on the library: some compulsions are beyond cure!
Thanks so much for saying this. Those thoughts hold me back when I'm thinking about starting an open source project. I already do lots of coding at work. I'm single and no kids, but spending a large amount of time on it in my free time would totally wreck my balance. I love coding but I also need non-technical activities in my life.
The author posted a follow-up piece:
<a href="https://www.drmaciver.com/2015/04/surprise-feminism/" rel="nofollow">https://www.drmaciver.com/2015/04/surprise-feminism/</a>
Daniel Compton: Open Source Is Free As in Baby: <a href="https://danielcompton.net/2014/11/19/dependencies" rel="nofollow">https://danielcompton.net/2014/11/19/dependencies</a><p>> I think of someone releasing open source software as a gift to the world, not as claiming a responsibility to maintain it for you. Some projects do claim that responsibility, but it’s not automatically conferred just because someone released a project on GitHub. I think much more of the responsibility falls on the person using it.
The nice thing about your shitty code is that it's <i>yours</i> and you don't have to open source it if you don't want to.<p>However, we live in such paranoid times, that if you do release a project and don't open source it, people will immediately convince themselves and others that you've bundled malware
in it. It's a sad state of affairs.<p>Code well, or code badly, Open Source or don't. It's your life, do it your way.
It's a matter of expectations. I believe expectations are extremely important when releasing anything creative, be it code or art or writing.<p>You might release something as a side project of a hobby, but people will become angry with you if it doesn't do what's advertised. This is significantly amplified if you go out of your way to tell people the project exists, in the hopes of it becoming popular and used. It can't become popular if it isn't good enough. That's the same for many different disciplines and various subjective standards of "good." In the case of software correctness is often stressed, unless it's generative art or something. So by marketing something in the hopes of it becoming popular you obligate yourself to getting it to the point where it can become popular.<p>So it's about not looking arrogant by saying something is true about a project when it isn't.<p>The problem isn't as simple as "don't mind if it's bad." Your library could end up being used in hundreds of projects. People want continued maintenance in this case. They might start filing issues against your project because of unforseen downstream bugs. But you might not feel like maintaining it anymore. Motivations change. But you'd have to be careful if you choose to hand off maintenance, because this can happen: <a href="https://github.com/dominictarr/event-stream/issues/116" rel="nofollow">https://github.com/dominictarr/event-stream/issues/116</a><p>So it isn't just a case of whether or not the code itself is bad. It's also about how you market the code to others. Ward people away if it's not production-ready. Sometimes undersell and never oversell. Remove any reason for people's expectations to be out of sync with the actual quality. In the case of event-stream the old maintainer became relied upon and then made the incorrect decision of letting an untrustworthy person have access to the code.<p>And also make clear your motivations. The creator of uBlock Origin states he might get bored of the project and move on. Give yourself an escape hatch like this so you can excuse yourself if you believe you really can't find yourself with the will to keep working on it in the future.<p>As long as those expectations are very clear to anyone who uses your code, then it is okay for public code to be bad.
Reminds me of that rust developer who wrote a super-fast webserver... and was trashed by the rust community for not upholding their standards.
When he finally had enough and said he was going to (IIRC) delete the project, suddenly people started being nice.<p>People never fail to impress me negatively.
Even outside of open source one of the things I always have to get over is ... writing bad code is ok.<p>Like not fixing it when you can or know better is not good, but in the meantime the code isn't going to be poetic and just write it already...
A fair answer:<p>"Since you have arguments why it's shitty, I encourage you to use that knowledge to improve that library, since you're free to improve it"
Yes, it is OK. Any software is allowed to be shitty as long as it works. But then people always go out of their way to tell you how shitty it is. The type of immature dev people who hang about here on Hacker News TBH. I ignore the mails, the terrible opinions because there are people who love what I do, although underneath it is not perfect.
Github should seriously think of making amount of time spent by developers behind a repository.
Even a rough heuristic will do.<p>This can include not just the time spent on code, documentation, tests, issues.<p>I guess, it would help other developers empathize better with individual developers who do it for no monetary gains.
definitely no it's not, by no mean
if it is shitty don't even bother uploading it to github.<p>there is already enough and more than enough amount of this type of projects.
So, we like to have some clickbait on the front row? Ok. I have a few more.<p>PHP: it is OK to be a bit shitty.
Javascript: It is OK for your type system to be a bit shitty.
Javascript: It is OK for your semantic consistency to be a bit shitty.
Java: it is OK for you syntax to be a bit shitty.
Java: it is OK for your value semantic to be a bit shitty.
MongoDB: it is OK for your design decisions to be a bit shitty.
node_modules: it is OK to be totally shitty.<p>I could go on and on.