
Why I'm Frequently Absent from Open Source - msoad
http://jlongster.com/Why-Frequently-Absent-Open-Source
======
nstart
On a tangential note, I wonder if this says something about the way in which
open source is delivered in a github world? Some of the best parts of open
source was the flexibility. Someone isn't maintaining a project you want?
Maintain it yourself. Or switch to something that's being maintained by
someone else.

This is a rather abstract thought so I apologise in advance for it. I'm
wondering what an open source world/tool that embraced that fluidity might
mean for end users and core maintainers. Assume a tool called gitworld existed
that did this. It might look like something where you can see which forks are
best maintained. Community discussions can happen around all the forks as
opposed to being against a repo by repo basis. So issues and PR's created
could be applied by default to all forks and we might see which forks have
closed these off? If I open an issue and a maintainer fixes it on her fork,
the issue would show me that it's closed there and the final build exists
there. It might also be really neat to have builds that become portable across
forks so when someone forks my repo, as they work on it their code gets built
and packaged automatically if I've done the necessary work to set those up.
(not a very practical idea given resource constraints but it would be neat).

Like I said, it's an abstract thought but given the trend that we are seeing
in open source management challenges, I'm wondering if it's time for a
paradigm shift as it were in managing open source projects, communities, and
expectations.

~~~
gaxun
I have posted a couple things related to this but never finished a complete
summary of my thoughts. These two attempts come close:

In [0], I shared some really basic thoughts about how this could be done by
users of a particular VCS package, git. Two line summary:

    
    
      You run `git announce [name] [tracker]` to tell a git tracker
      that you've got your own fork. If you host your repository
      in a public place, the tracker just checks your repo for
      updates so other users can stay informed.
    

At [1], I describe a similar system with a specific type of frequently-forked
software (GPL'd tools). This seems less tied to using git. This software is
available from diverse sources in multiple VCS systems and may be wildly
divergent. Comparing the sources seems valuable, but difficult.

Alternatively, Fossil does "distributed version control and issues", but it's
really just meant to be one central location for a particular project.

Thought I'd share. I'm on board with everything you're saying. There are
clearly some issues as well, though. The biggest one I see is related to the
"paradox of choice" \-- when there are four forks all just one commit
different from each other, how do you know which one(s) to use? This is why we
usually just follow the leader (maintainer) and use the one true source. End
users don't have the ability to quickly know which patches to accept and
reject. Even a reputation system wouldn't necessarily provide clean signals,
due to bandwagon type effects.

Unfortunately, I already have enough trouble picking between `iron` and
`nickel` as a Rust web framework.

[0]: [https://www.gaxun.net/ideas/git-
announce/](https://www.gaxun.net/ideas/git-announce/)

[1]:
[https://news.ycombinator.com/item?id=13028079](https://news.ycombinator.com/item?id=13028079)

------
pryelluw
The point about open source being charity really resonated with me. It's like
volunteering at a soup kitchen that cooks the best food in the world that then
gets repackaged by a third party and sold at a huge profit and none is given
back to the soup kitchen. WTF.

~~~
holri
This is why Copyleft exists.

~~~
pjmlp
This is why companies like Apple and Google are ditching all projects that
they can from their products, e.g. GCC is on the way out on Android NDK and
Fuschia/Magenta almost doesn't have any (L)GPL related components.

Also why so many companies are happily making web apps, with everything behind
server walls.

~~~
ue_
>Also why so many companies are happily making web apps, with everything
behind server walls.

Which is why the AGPL exists.

I would rather have few people use my software than have it used as part of a
distribution that is sold for profit by an organisation making use of
extracted surplus value.

~~~
kartickv
What a negative attitude. You seem more interested in preventing others from
benefiting than anything else.

I wouldn't have used the phrase "extracted value" because, unlike coal, using
it doesn't deplete it. The world isn't zero-sum.

------
teekert
I think running an open source project can only work for you if you have a
certain level of give-an-f-ness (hail Linus). Beware, there be morons on the
internet. Loads. Be very careful not to waste any emotion on them, do stuff
for yourself, to make _you_ feel good! Of course this can be charity, charity
can make any non-sociopath feel good.

There is a very large, appreciative silent majority out there that love what
you do and use your stuff without telling you everyday that they love you. And
then there are some vocal lowlifes that feel some sort of entitlement to your
time.

~~~
joeyespo
It's a shame opening an issue can so easily be used as a frustration outlet,
yet there's no equivalent feature to show that you love a project without
burdening a maintainer with an issue.

I personally enjoy being on both the sending and receiving end of message of
thanks.

Projects like this recognize this and can perhaps help break that silence of
the majority
[https://github.com/kennethreitz/saythanks.io](https://github.com/kennethreitz/saythanks.io)

------
deadlyllama
How does this work when you're a member of the "github is my resume" crowd? Or
do you have to leave that crowd when you have children?

GitHub is not my resume. No one has paid me to work on open source outside of
a few isolated instances - I did port an RDP client to SVGAlib once.

~~~
watwut
Members of "github is my resume" either don't work on critical projects that
are under time pressure or don't have jobs that require them to code a lot. I
was much more open to hobby coding when the job had unreasonable amount of
meetings (or other socialization). When I was focusing on code/design most of
daytime, I found out I was too tired even before 8 hours ticked.

Coding meant I will be less productive next day and besides, I was already
coding a lot and getting better at it in work. I found it more rational to
focus in my free time on things that job wont teach me.

~~~
ugexe
Not everyone is tired of coding after a day work just because you are. Do you
think the top professional athletes have that type of attitude?

~~~
watwut
Yes, professional athletes do recovery. They spend time wi th baths, massages
and take (legal) supplements to speed the whole process. They also train super
intensively, they do not train for 12 hours a day.

If you are not tired after whole day of coding, then you was not coding
intensively enough or did not had to solve difficult enough problems. Of
course I can slowly hang around easy code for hours. It is different when you
are trying to be as fast as possible and still not sacrifice the quality.

------
buovjaga
> Somebody, or a group of people, needs to step up and spend lots of hours
> every week to make sure code actually gets pushed through the pipeline and
> issues are triaged.

This article is describing a delegation problem. The project mentioned,
prettier, is developer-oriented, but let's take this to a general level.

You have to start recruiting your users to the various non-coding teams from
day one. Then those users need to pick up the responsibility of recruiting.

I have not contributed a single line of code to my project of choice,
LibreOffice. Yet, over the past few years I have

\- triaged thousands of issues

\- done tech/process documentation in the wiki

\- done research on web applications + a little maintenance work on them

\- recruited people to the QA team

\- recruited people to the infra team

\- recruited people to the design team

\- mentored new developers (on the process, not code), even through submitting
their first patch

\- offered guidance to new contributors in every team (who is who, how to
start, what tasks are available etc.)

\- made sure information flows between the teams

\- given a bit of user support (some bugs are user errors..)

There are innumerable ways non-coding users can help preserve the sanity of
developers. You just have to let the users know. You have to spell it out for
them, they do not know how important this simple stuff is. I did not know
about it, when I started dabbling with bug testing - it was an accident!

~~~
vog
This. Exactly this is the problem with semi-popular Free Software projects,
and what annoys me most with almost-but-not-quite unmaintained projects.

It is really no problem if somebody's time is limited. But it is a problem if
they don't delegate properly, and thus make it very hard for volunteers to
assist them, or to even take over when the time arrives.

It's not so much about doing not enough work, it is about preventing others
from coordinating their work on it.

Unfortunately, many people don't notice that they are actually doing this.
They try to review more and more contributions, work starts piling up, but
they link their problem is missing time, while it really is missing trust.

Also, this transition is much easier when you still have some time. When you
arrive at a state where don't have any time at all, it is really hard to
perform proper delegation, and one or two (hopefully not too much
uncoordinated) forks are they only way for the community to reorganize.

------
Derbasti
This is so true. Open source is something I do on my spare time, _if_ I have
spare time available. And it often is absurd how some people seem to demand
quick response times and prompt bug fixes from open source projects.

I have burnt out of one high-volume OSS project (and co-maintainer) before,
and it wasn't pretty. Not for the project, not for my well-being, and not for
my co-maintainer. Since then, I have been very careful about OSS commitments.
I still do a lot of OSS stuff, but I don't promise any time scales any longer.
That way leads to stress and problems.

~~~
pryelluw
I wrote about how I manage it here: [https://dev.to/yelluw/10-things-i-do-to-
keep-open-source-pro...](https://dev.to/yelluw/10-things-i-do-to-keep-open-
source-projects-healthy-and-stress-free)

Seems we are following similar paths. :)

------
RodericDay
> Unfortunately, in reality open source development is rife with problems and
> is ultimately unsustainable.

This is an absurd statement given the popularity and staying power of numerous
open source projects.

~~~
yazaddaruvala
Not "unsustainable" for the project or technology, "unsustainable" for the
human(s) supporting the project or technology.

~~~
radicsge
And that is exactly one of the reason of the opensource, to get more
contributor.. (instead of releasing e.g. binaries..)

~~~
jfim
You'd be surprised how many contributors actually have a negative effect on
the productivity of core developers. New contributors often require a fair bit
of hand holding (just like any new contributor on a codebase, even internal
ones) and are not necessarily aware of the general project direction, etc.

More contributors doesn't mean more productivity, and often means less, not
more.

------
webaholic
It's not impossible to set up an open source project where new contributors
don't need hand holding. Set up a contributor check list and running automated
tests will get you half way there. For the rest, you depend on the community
you create by encouraging contributions.

~~~
sethherr
1\. People don't follow the checklist

2\. People don't understand how to fix broken tests

This piece is about is that exactly. Closing those PRs. Not responding all the
time. And that being ok.

------
badosu
Unfortunate to see this not being in front-page right now.

I feel posts like this are necessary for people to have more perspective into
things, and also raising issues that might be not obvious and easily dismissed
in our current FLOSS praxis.

------
qplex
I don't see how this is specific to open source software.

Would you feel guilty if you were absent from some other activity because of
family?

------
fpgaminer
One day I got a pull request for one of my GitHub projects. It was unexpected.
The project is an encrypted backup solution, written in Rust. It's very WIP
([https://github.com/fpgaminer/preserve](https://github.com/fpgaminer/preserve)).
The pull request was unexpected because I haven't really advertised the
project; it's very rough around the edges.

This wonderful fellow added additional backend support to the code; it's a
rather huge diff; lots of work on their part. It made me feel really good to
know that someone thought my project was worth that effort.

I let the requester know that I was quite busy and wouldn't be able to get
around to reviewing and merging the pull request for awhile. That was ... I
dunno, several months ago now. I feel really bad. Every time I go over my TODO
list I see it and just ... just feel awful about not having gotten 'round to
it yet.

Part of me feels bad because, for me, when I make pull requests against
projects, I check the status of the pull requests obsessively. It's a bit of
vanity I suppose; validation that someone else likes my code and work enough
to fold it into their grander project. It's silly, because I don't ultimately
need the validation. I accomplish enough in my career, but ... I still get a
thrill from having my pull requests merged, silly or not. So I feel bad,
because I figure this person probably feels the same way and is wondering why,
after all this time, I couldn't be bothered to merge the request.

Part of me feels bad because I want to cultivate a healthy open source
presence for myself. Why? I'm not sure, actually. But regardless, having pull
requests sit open in my repos for months on end is not really helping foster
any sort of reputation for myself; at least not a good one.

And part of me feels bad because that project ... I care about that project.
It's actually really useful for me. But I haven't worked on its code in
forever. Outside of my professional work I have the hardest time finishing
projects. I've always been like that, always jumping from one idea to the
next. The "Archived Projects" folder on my computer is probably 1000+ thick
now with half finished things. All cool, interesting things.

Unlike the article's author, I don't have an excuse really. It used to be that
I was too busy. I worked at a startup, and I'm sure most people here on HN can
appreciate how much free time that left me. But now that that startup is
behind me I've taken some time off to recharge my batteries. I don't have an
excuse not to work on the things I want to work on, other than when I sit down
at my computer and ask myself "What should I work on today?" my mind jumps to
whatever the flavor du jour is in my litany of ideas. Always something new;
never anything completed.

I'll get around to reviewing the pull request and merge it one day. I really
will. But it won't make me feel better, because it sat there rotting for
months. And I don't think the pull request's author will be happy either.
They'll probably be surprised I even remembered. "[I]t's OK to neglect a
project for a while" doesn't make me feel better. Knowing that it's charity
doesn't make me feel better. I put way too much of my value into these
projects...

~~~
kens
If you've got pull requests you never get around to handling, I recommend the
"Pull request hack"†: give the requestor commit access. This has worked well
for me, and reduced my stress, and gained me a contributor who looks after the
project much better than I was.

†
[https://news.ycombinator.com/item?id=5357417](https://news.ycombinator.com/item?id=5357417)

~~~
dubberx
> give the requestor commit access.

Why wouldn't a requestor just fork the project and continue from there?

~~~
Flenser
They've already forked the project in order to make the pull request. The pull
request shows that they'd like to also fix the issue for all the users of the
original repo.

------
thomastjeffery
You pointed out three major issues, and I'd like to try to address them,
because I wholeheartedly agree with you, and I also,

> love open source!

I don't have any real solutions, but I want to express my perspective anyway.

> Somebody has to pay the cost of maintaining a project.

Yes. The beauty of free software is that it _does not_ have to be _you_. That
being said, it tends to be you anyway, doesn't it? The same can be said of any
side-project. The beauty is that _you_ didn't lay claim to that
responsibility. Since you clearly don't have the time, and rightfully so, you
have lessened your contribution, or even abandoned the side project. The
beauty of this is that you allowed everyone else the _freedom_ necessary to
take over. Anyone can fork free software if they so desire. The same cannot be
said of proprietary/closed-source software. I count this as a win for free
software, not a problem.

> when we try to work together, and open source has little structure for
> dealing with these problems

Like Richard Stallman, I am a stickler for words. The reason I (and Stallman)
are pedantic in this case, is that I (as he) want to emphasize the real issue:
Liberty. For that reason, I agree with him that "Open Source" is a poor
representation of "Free Software". Why do I bring this up now? You mention
structure. Freedom does not create structure; and yet, the culture that
encompasses free software is very organized. That organization, however, is
very different from the culture of a business. Here are a few key differences:

* No one is obligated to work on this. * No one is paid to be in charge.

Unlike a traditional business with employees and management, nothing is
imposed. The upside is that free software can evolve in ways the managers and
employees either would not dream up, or simply do not have the resources or
time to implement. The catch is that unless someone wants to actually do it,
and that someone has the time _and_ skill, that innovation simply will not
come to fruition. Businesses have the one thing that free software is missing.
Almost as a pun on its name, it has no direct monetary value.

> projects go open source just for the "warm fuzzies"

> call it for what it is: charity.

This is far and wide the perspective any business has on free software. This,
I believe, is the root of the problem. We as software engineers need money. As
much as some of us might enjoy late nights working on projects for free,
everyone who lives a full life needs an income.

Looking through the lens of impossible optimism, I see a world where companies
can accept a different business model:

When a business needs a piece of software, they hire developers to create it.
The devs get paid, and the business gets what they needed. The key difference
in this alternate reality is that the business does not consider software (or
any other "intellectual property") as a physical commodity. The software is
instead, open, and free. Anyone can use, adapt, repair, etc. the software that
was created.

The root fallacy is to equate software (or any digital property) to
commodities. Businesses tend to get the notion that if they do not hold onto
their property, they are giving it away. Ford does not build a car to give
away; that would be as detrimental as theft! In this situation, Ford is out a
car. The difference that makes software, etc. unique, is that you _can_ give
it away _without losing it_. If more than one related project is free
software, both projects benefit, and even more value comes out of what _prima
facie_ is mere charity. That is why I firmly agree:

> I think it's a net win for society, even if there are big problems we still
> need to solve.

~~~
pjmlp
> Businesses tend to get the notion that if they do not hold onto their
> property, they are giving it away.

They are giving their IP away, the secret sauce how many business decisions
are taken.

On companies whose business is not related to software, their in-house
software contains lots of information regarding business rules how the whole
company is managed.

On companies whose business is product development (not consulting), the
software is the very reason the company exists, allowing others to re-sell
their core business would drive them out of business.

Hence why FOSS only works when the incoming is coming from sponsors,
consulting companies, training and selling books.

------
oliwarner
Edit: This attracted more downvotes than I had expected. What am I saying that
is wrong here? Please comment.

I'm _not_ saying that family isn't also important —it is, I have one— just
that I disagree with the opening hypothesis that open source is "ultimately
unsustainable". It's completely sustainable both personally and commercially,
it's just about finding your balance and as others have since said, reaching a
point where you can delegate.

\---

That's an _awful_ lot of crapping over the ethos of open source just to say
"I've got better stuff to do".

And all that assumes that time invested into running an open project is
wasted. If you don't think your project is making the world an objectively
better place, why the hell are you doing it? And that's not to mention the
amount of work I've gotten off the back of being able to display my expertise.

Seriously. Open source is an investment in the community and in yourself. Like
any other investment, you can make bad investments and you can make good
investments and still need to exit early because you need the [time] capital
back.

But that doesn't mean open source isn't good, has a place, isn't worth it.

