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.
In , 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.
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.
The alternative is to sell licenses.
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.
I wouldn't have used the phrase "extracted value" because, unlike coal, using it doesn't deplete it. The world isn't zero-sum.
(The AGPL being the exception here.)
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.
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
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.
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.
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.
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.
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!
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.
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.
Seems we are following similar paths. :)
This is an absurd statement given the popularity and staying power of numerous open source projects.
More contributors doesn't mean more productivity, and often means less, not more.
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 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.
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, 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.
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.
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.
Code contribution guides and Continuous Integration systems will only get you so far.
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.
Would you feel guilty if you were absent from some other activity because of family?
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...
Why wouldn't a requestor just fork the project and continue from there?
> 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.
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.
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.