
It’s OK for your open source library to be a bit shitty (2015) - mmcloughlin
https://www.drmaciver.com/2015/04/its-ok-for-your-open-source-library-to-be-a-bit-shitty/
======
Justsignedup
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.

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.

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.

~~~
CalRobert
Unfortunately, DINKs are hard to compete with professionally. Old boss used to
loudly thank my colleague for doing tickets on the weekends, and too often
people seem to assume I want to spend my weekend "brushing up" on some
implementation detail for a project I don't care about. Even "why doesn't he
come to after work drinks?" Is hard to answer with "because my spouse is
_also_ an exhausted wreck at the end of the day and I already barely have any
time for them, much less my real friends, much less you lot".

~~~
BurningFrog
> _Unfortunately, DINKs are hard to compete with professionally_

Sure, but people with kids win at life.

Let the DINK make some extra money. You still have it better.

~~~
ssanders82
> people with kids win at life

That's a pretty insulting statement for those of us who can't have / don't
want children.

It's not a competition. We've chosen different paths than you. Not worse, just
different.

~~~
zhoujianfu
Agreed... I remember a study on “do kids make you happier” and their
conclusion was “kids make you happier if you want kids”.. people who didn’t
want kids but had them or wanted kids but couldn’t have them were sadder, but
people who didn’t want kids and didn’t have them were just as happy. Which I
guess makes sense... people are happy when they get what they want!

~~~
nbardy
If you're having kids you're striving for things that aren't happiness. Often
trading exhaustion for purpose and meaning.

~~~
saagarjha
If you want kids and you have kids it certainly looks like you are striving
for happiness.

------
saurik
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 _necessarily_ make the world a better place
_just_ 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 _even though_ "it
is ok for you to not really know how to cook or not have that much time and
participate in the potluck anyway".

~~~
wolco
"sure: it is totally their fault for deploying something without carefully
reading your code to figure out that it was a bit shitty beforehand"

Yes you must read and understand everything or have trust in the publisher.
Relying on the package name is going to get you in trouble. Sounds like a
great exploit opportunity.

~~~
sabas123
What if I have no reasonable way of fully understanding the code nor being
able to judge the author on their trustworthiness (even disregarding that this
isn't constant).

As a community we need to accept that the above mentioned DOES happen.
Pretending otherwise only hurts us all.

~~~
TeMPOraL
> _As a community we need to accept that the above mentioned DOES happen.
> Pretending otherwise only hurts us all._

In fact, it happens very often when people are learning and exploring. So
imagine I publish my shitty library "with a generic name and a description
talking about how awesome it is". Imagine you're trying to learn $language.
You buy into my deception and try to use my library. You get burned, and might
be left with an impression that $language or its ecosystem is shitty, and
never return, despite the fact that $language would suit the kinds of problems
you're solving really well. If it happens enough times with enough libraries,
$language may get a bad reputation. Preventing this becomes a matter of
protecting the common good.

~~~
bigiain
Hands up everybody who remembers "Matt's Script Archive"?

(Hmmm, just the greybeards. I could have guessed that I suppose...)

------
tych0
I've used and been the maintainer of a "shitty" open source window manager off
and on for the last 10 years.

I love the project. People at my last few companies joke about it. But it's so
fun.

Who cares if it's shitty. Ride bikes and write code.

~~~
dmpayton
Some of my favorite memories of open source involvement have been contributing
to that "shitty" project. Thanks for helping to keep it going!

~~~
tych0
Yeah! Thank you too. The excellent web pages and docs would not be there
without your efforts.

------
nerdbaggy
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.

~~~
franciscop
I have few projects on 1k+ stars; the ones that are more beginner-friendly are
normally where I get most unrelated requests. I used to help people where
possible, but now I just don't have the time (or TBH, motivation).

So I closed the issues on those two projects that got most low-quality issues.
People started to open PR to tell me I was wrong and I should open the issues.
This cemented my decision, oh the entitlement of some people.

~~~
noitsnot
I think that's understandable. You closed issues for bugs you didn't resolve.

~~~
sgillen
Maybe you know the OP, but in my experience a lot of issues are not bug
reports but very low quality, uninformed or unreasonable requests or
questions. Like questions made about basic functionality that is answered in
the documentation/faq, or requests for features that are completely outside
the scope of the project. Another popular category is requests for basic
education e.g. “how does DQN work?”. That’s fine if it’s one person but when
it’s 100 it gets overwhelming.

~~~
stickfigure
Sure. On the other hand, sometimes people put a lot of time and effort into
isolating an issue and writing up the best description they can manage.
Closing the issue is a one-click FU to the people who are doing their best to
help.

Some users are overly entitled, but some maintainers are self-absorbed
douchebags. I've seen both sides.

~~~
cellularmitosis
I will never understand this point of view. The author has already given you
possibly hundreds of hours of free labor simply by publishing the project. But
now, because they won’t give you a few more, they’re a douchebag?

Even if they close all issues with no comment, they have given you a such
_massive_ head start vs having to write the entire project yourself from
scratch. How can you be anything but grateful?

~~~
sgillen
It's just that if you put lot of effort into isolating a bug for someone for
free, it can feels bad to have it rejected without explanation.

Also if it's a real issue that you won't fix you should at least leave the
issue open so other people know.

IMO you can definitely be extremely grateful for someone's contribution and
also think they are sort of rude, not incompatible views/feeling.

~~~
dragandj
> ...isolating a bug for someone...

I think you mistakenly switched the roles there. You are not isolating a bug
for the author. The author is using their software and is happy with its
current state. It is you that is being hit by a supposed bug, and you are
isolating it for yourself. Then you are expecting the author to do the
additional work for you and handle your supposed fixes. Don’t get me wrong,
you’re probably both helping each other in the best spirit of open source, but
it’s not you who’s the ideal of generosity there.

~~~
franciscop
This a thousand times. If you hit a bug on my code and put together a PR to
fix it, the reasons I would merge it are in order of importance:

1\. For you, since you are nice and helpful debugging it and fixing it for you
and others so I want to make it easy for you to use the working code.

2\. For other users that might hit the bug, for every PR bugfix there are
likely N people hitting the bug.

3\. For me in case I hit it in the future.

4\. For correctness sake.

But not all bugs are straightforward, many have side-effects or disadvantages
that I might not be comfortable merging straight away. So I have to evaluate
how long it'll take me to review the PR and whether it's even worth-it (the
vast majority of times PRs are worth-it, but issues are a hit and miss).

------
nanoscopic
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.

Essentially; do publish all work you possibly can, simply be clear about what
the software does or does not do.

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.

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.

~~~
ProZsolt
If you want to others use it, then document it. I really appreciate it.
Otherwise, if you only wrote it for yourself you did enough. Undocumented code
is better than no code. If you didn't publish at all I would have to start
from zero.

------
harikb
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.

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.

At the very least they can make it easy to ignore forks where

1\. changes have already been merged upline 2\. forks that only have cosmetic
changes of imports (happens a lot for Go repositories)

This will allow the developer to pass the torch, so to speak, to someone else
willing to maintain their own fork.

~~~
cellularmitosis
At scale, how do you tell the difference between software which is finished vs
software which is unmaintained?

~~~
chadlavi
"Finished software" is a myth.

~~~
cellularmitosis
Though I love a good fatalistic Jamie Zawinski reference, I’ll resist and stay
on-topic. I think you mean “for the kind of software I typically get paid to
write, software is never finished.”

However, if you widen your perspective a bit, you’ll find plenty of examples.
I assure you, “space invaders” was finished in 1978, and it will never see any
“maintenance”.

~~~
chadlavi
I mean yeah, every piece of commercially available software got shipped at
some point, and especially before the internet that software was mostly done
being changed forever. That doesn't mean it was finished!

------
galonk
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.

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.

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.

~~~
speedgoose
Why would your employer decide what you do on your spare time?

~~~
cyphar
Not everyone wants to (or is able to) to work on projects in their spare time.

~~~
speedgoose
Oh yes I didn't read well, my bad.

------
leibnitz27
I have an OSS 'fun project' \- I'm still amazed by the number of issues/emails
I get raised which say:

"You should rewrite in" / "Why does't it do" / "Make it do".

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 _in English_.

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.

I'd get the same issues raised, and that's fine. But the language might read a
bit nicer.

~~~
rmetzler
Thanks for acknowledging this might be a language or cultural thing. I’m sure
this kind of „smalltalk“ is appreciated when you put your free time into what
others maybe use for their job.

One thing I would like to suggest is to have a question in the feature or bug
issue template to ask what people use the lib for and what they like about it.
Maybe even set expectations.

------
andrewstuart
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."

~~~
hombre_fatal
The first thing you learn when you're proud of your Github profile is that
nobody is actually clicking into your projects and reading code, with few
exceptions.

Sure, at small companies where developers interview you, or maybe if you link
to a specific relevant project in your cover letter, you might get a pair of
eyeballs. But I think people vastly overestimate the readership of their repos
when looking for jobs.

~~~
aetherspawn
I learnt this when I uploaded a project that claimed to do something but was
only like 10% finished and you couldn’t run it.

It got cross-posted across the internet and a ton of stars and even referenced
in some else’s project repo as a competitor/alternative and reasons why theirs
was better!

This experience really made me smile. Nobody even tried to run it.

~~~
TeMPOraL
FWIW, stars on Github aren't means of expressing that you've tested and liked
something; they're means of _bookmarking interesting repos_. So it's entirely
plausible you got hundreds of stars and nobody ever run the project. Myself,
I've stared close to 300 repos, and have run maybe a handful.

------
dnautics
As the author of shitty open source libraries I agree, but a bit of a
disclaimer in the readme should be expected.

~~~
matheusmoreira
> a bit of a disclaimer in the readme should be expected

Every project already has these. They're in the license files.

> This program is distributed in the hope that it will be useful, but WITHOUT
> ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> FITNESS FOR A PARTICULAR PURPOSE.

This disclaimer is clear, self-explanatory, legally binding and a standard
feature of all licenses. So why do people assume they can use random code from
random developers they never met without even looking at the source code?

~~~
brabel
> So why do people assume they can use random code from random developers they
> never met without even looking at the source code?

Because that's open source, and has worked well for a lot of things.

~~~
watwut
That us not how open source ever worked. You get high quality open source from
established projects and stability from governance. By governance I mean
something like apache or eclipse or linux foundation that forces projects to
be lead in certain way.

Random code from random people always had varios quality - from great to
horrible.

------
ExtremisAndy
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.

~~~
gus_massa
Start fixing typos in the docs and error messages in projects _you_ use.

Try to send bug reports and look at how they fix it. Sometimes it is even
difficult to find the file that must be fixed. Perhaps next time you spot a
bug, it is in the same file and you can fix it.

Start with small changes, I recommend not investing more than one of two
afternoons because the maintainer may not merge it. Perhaps because the code
is bad, perhaps because it doesn't follow the (implicit hidden) spirit of the
project, perhaps because the maintainer is a moron.

Try to follow the nearby code style. Each project/maintainer has preferences.
If you break them, the maintainer may ask nicely to fix them before merging.

(If they are not nice, just forget about the project. You have lost only two
afternoons.)

(Whitespace changes is a hot topic, try to avoid whitespace changes unless you
know the local policy.)

------
mceachen
As both an open source author/producer and consumer, I wish more projects were
forthright about:

0) known defects

1) when the author no longer uses the library themselves

2) the repo is abandoned and alternatives are not given

There's a _lot_ of abandoned code out there. It'd be nice if package managers
had abandoned-package detection built-in.

~~~
franciscop
The problem is that in practice there are many times that the visible
different between "done" and "abandoned" is null, specially for smaller
single-purpose libraries.

~~~
TeMPOraL
Or mature, stable ecosystems. People use Common Lisp libraries that haven't
been updated in _20 years_ , because they _work_.

------
bredren
I just picked up maintainership of django-address. It is a set of models and
methods for dealing with postal addresses in Django.

The product is dominant in seo and many django beginners and intermediate
install it without looking at it.

But it has also languished for years and failed to get an important model
rearchitecture after the author had to stop work on it.

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.

I think this article is for the author, Luke, who made this for himself for
Australian addresses when django was still a smaller framework.

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.

~~~
imgabe
Glad to hear someone is picking up maintenance for this! I found it via Google
a while ago and ended up forking it to make it play more nicely with Google
Maps. I really appreciated the starting point though and that a lot of the
heavy lifting of creating a custom model field had been done.

~~~
bredren
Right on. Please reply in the 'path forward' issue with a link to your fork.
I'm interested in learning how people have taken upon themselves to improve
the package.

------
zoomablemind
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.

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.

------
quercus
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.

------
conroy
I maintain an open source project with ~2k stars
([https://github.com/kyleconroy/sqlc](https://github.com/kyleconroy/sqlc)).
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”.

~~~
tomkwong
You can probably leave the sorry part out. There’s nothing to be sorry about
:-)

~~~
random32840
Text is ambiguous, overtly communicating that you aren't trying to be mean is
a good idea IMO.

------
1-KB-OK
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?

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.

------
glangdale
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.

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 _lot_ quicker than you would if you sat around
"perfecting" it.

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.

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.

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 _dreadful_ substitute for libpcre if you wanted a
featureful single-pattern non-streaming regex implementation.

------
rlayton2
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.")

------
rikroots
From the article:

> 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.

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.

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.

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.

... But whatever happens, I'll still continue working on the library: some
compulsions are beyond cure!

~~~
tenaciousDaniel
what's the side project?

~~~
rikroots
[https://github.com/KaliedaRik/Scrawl-
canvas](https://github.com/KaliedaRik/Scrawl-canvas)

------
posedge
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.

------
Quanttek
The author posted a follow-up piece:
[https://www.drmaciver.com/2015/04/surprise-
feminism/](https://www.drmaciver.com/2015/04/surprise-feminism/)

------
underdeserver
Missing (2015), though the message is timeless.

~~~
dang
Added. Thanks!

------
nayuki
Daniel Compton: Open Source Is Free As in Baby:
[https://danielcompton.net/2014/11/19/dependencies](https://danielcompton.net/2014/11/19/dependencies)

> 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.

------
Jaruzel
The nice thing about your shitty code is that it's _yours_ and you don't have
to open source it if you don't want to.

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.

Code well, or code badly, Open Source or don't. It's your life, do it your
way.

------
nonbirithm
It's a matter of expectations. I believe expectations are extremely important
when releasing anything creative, be it code or art or writing.

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.

So it's about not looking arrogant by saying something is true about a project
when it isn't.

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: [https://github.com/dominictarr/event-
stream/issues/116](https://github.com/dominictarr/event-stream/issues/116)

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.

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.

As long as those expectations are very clear to anyone who uses your code,
then it is okay for public code to be bad.

------
LockAndLol
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.

People never fail to impress me negatively.

------
pfdietz
If you find an open source library that could be better, and you are using it,
make it better yourself.

~~~
random32840
This is naive. If it's a bad library full of bugs, it's going to be garbage
code. I'm not going to spend inordinate amounts of time & effort wrestling
with shitty code to earn the right to say the library is bad. IMO that's not a
good standard.

~~~
pfdietz
I wasn't saying you couldn't call it bad. But I will say demanding it not be
bad would be stepping over a line.

If money ever changes hands with the author of that code, that's a different
story. But if it's something free you just found, and you have never paid the
author anything, then at most you can warn others to not waste their time. You
are in no moral or legal position to demand anything.

~~~
random32840
You're right, I misread. I apologise.

------
duxup
Even outside of open source one of the things I always have to get over is ...
writing bad code is ok.

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...

------
jokoon
A fair answer:

"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"

------
altitudinous
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.

------
samblr
Github should seriously think of making amount of time spent by developers
behind a repository. Even a rough heuristic will do.

This can include not just the time spent on code, documentation, tests,
issues.

I guess, it would help other developers empathize better with individual
developers who do it for no monetary gains.

------
Upvoter33
Not everything worth doing is worth doing well -Tom West

------
coronadisaster
It is not ok if you want open source to take over the world.

------
Gother01
definitely no it's not, by no mean if it is shitty don't even bother uploading
it to github.

there is already enough and more than enough amount of this type of projects.

------
johndoe42377
So, we like to have some clickbait on the front row? Ok. I have a few more.

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.

I could go on and on.

