Why I'm Frequently Absent from Open Source | Hacker News Reader

Why I'm Frequently Absent from Open Source

jlongster.com

108 pointsmsoad55 comments

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.

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/

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

I like where you're going with that. I would love to see some innovation in this space.

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.

It's not always charity, some opensource to have co-maintainers, some opensource to show his achievement and put into his resume. Some opensource because then they can build something together as a community so he can also use it in the next-release (..instead of patching his version). etc.

You are right. My soup kitchen metaphor still stands (IMO).

This is why Copyleft exists.

That's what the theory says, but in practice you get a net loss since entities like Apple and the FSF will never stand on the other's ground effectively resulting in a deadlock.

Except that in a cloud world, you can run modified GPL'ed software on your server and not release a single bit, since you are not redistributing the software.

(The AGPL being the exception here.)

Has the AGPL ever been tested in court?

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.

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

AGPL doesn't matter because unless someone that works for the company comes public and denounces the situation, there are very little chances to know how the server stack actually looks like.

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.

No, that's not true. Copyleft does nothing to prevent others from selling copyleft code.

I thought that this is supposed to be whole point of open source. Once it is out, it is out and people can freely do what they want including profit. Open source people spend a lot of effort in trying to convince business that using open source is safe.

The alternative is to sell licenses.

No, it selling putting you recipe up for grabs and reaping the benefits of anyone making it better and more elaborate. What's to stop you from repackaging it yourself by they? With the official seal of approval from the makers on the package?

Here's a solution to that problem:

https://kartick-log.blogspot.in/2016/11/a-commercial-reuse-l...

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.

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

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.

You don't have a utility program you can't clean up and put on there?

Assuming you can clean it up, or put it up in the first place, and deal with future maintenance - assuming that whatever you put up ends up being enough for github-as-resume purposes in the first place...

There's a fair amount of stuff I'd like to throw up on github since I can't put any of my work-related code up, but I have other priorities in my life, so meh. My spouse is the total opposite of me and will probably struggle to come to terms with our impending spawn sucking up his free time, but that's just how things are. I don't think there's any shame to be had to not participate in these things regardless of the reason - it has a non-zero time and effort cost that cannot be ignored.

If you are a back end Node.js developer, check us out. We are currently hiring for an open source project.

https://lisk.io/

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.

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?

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.

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

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.

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.

I wrote about how I manage it here: https://dev.to/yelluw/10-things-i-do-to-keep-open-source-pro...

Seems we are following similar paths. :)

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

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

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

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.

Especially since FOSS pretty much runs the web, and has only grown in scope since the 80s & 90s when it was birthed.

FOSS has its problems, yes, but it's shown staying power and growth so far. I'm not so sure it's ultimately unsustainable. Mind you, I've never been a maintainer.

The OpenSSL debacle shows how well it runs the web.

The Web was born out of NeXTStep, Solaris, HP-UX, Aix, Atari, Netware, Amiga and MS-DOS/Windows stacks.

*BSD and GNU/Linux came afterwards, picking up steam as most ISPs, many just handling a few neighborhoods, would rather use them for free (beer) than paying for UNIX or Windows NT licenses.

I disagree. BSD UNIX, created way back in 1977, was already dominant in Internet networking in those early web days circa 1991, hosting the majority of university web content in the early days of the web (early 1990s). And back then, university-hosted content was basically all the web.

Sure, strictly speaking, the web was born on NeXTStep, but it definitely was suckled on BSD UNIX, and to a lesser extent System V UNIX, some of the others you mention[1], and VMS (what I used to host web content in the early early days).

1. with the exception of MS-DOS/Windows, which didn't even have native TCP/IP support in those days.

Maybe in US, not in many European countries.

In Portugal, most universities were using Aix and DG/UX, no BSD in sight back then. I was there.

Around 1995 they started to slowly move to GNU/Linux, but many of those Aix, DG/UX servers only got replaced by GNU/Linux when the hardware died for whatever reason.

There were quite a few TCP/IP stacks for MS-DOS/Windows available, that many of us just bought.

He was talking about smaller two man project not founded by larger organizations. Those highly popular open source project are developed by people who are paid for it. Majority of small open source projects dies and have no funds.

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.

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.

Right...People are the problem. More so managing people. Maintainers are there to develop code and not to manage people. It takes a lot of effort to organize and keep people in check. No checklist will ever do that.

It can be very hard to find individuals who you can give commit access to `master` for any non-trivial open-source project without having them break the build or introduce serious long-term defects.

Code contribution guides and Continuous Integration systems will only get you so far.

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.

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?

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

Maybe let the PR author know that it's still on your radar; that you haven't forgotten about it but that you're waiting for enough time to do a big slug of work.

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

I cannot upvote this enough.

> give the requestor commit access.

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

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.

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.

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

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.

Reply on news.ycombinator.com