[HN Gopher] Making is show business now (2020)
___________________________________________________________________
Making is show business now (2020)
Author : hgarg
Score : 159 points
Date : 2021-01-25 12:14 UTC (1 days ago)
(HTM) web link (alexdanco.com)
(TXT) w3m dump (alexdanco.com)
| danschumann wrote:
| I up voted based on the converse application to the headline,
| wherein a programmer makes his program more fun by adding ah
| fictional character to do his logging statements like a story.
| sgillen wrote:
| This is pretty discouraging honestly, from the perspective of
| what the article calls a "fan". I like to make small
| contributions to projects I use when I can, but I don't become a
| core dev on any of them.
|
| Is it really not worth the maintainers time to merge a bug fix or
| look at an issue I opened? Are they just doing it as "fan
| service"?
|
| Genuinely, does this type of "participation" really waste more
| time than it saves on the whole?
|
| That seems to be the implication of the article. I wonder if any
| open source maintainers can chime in.
| titanomachy wrote:
| The article doesn't say large fan bases are useless, just that
| managing them requires a different skill set (and possibly
| personality type) than conventional team management or pure dev
| work.
| centimeter wrote:
| This is one of my primary objections to the cultural shift of the
| last 10 years towards trying to attract tons of random people,
| especially special interest groups, into open source software
| development. If they weren't naturally going to contribute anyway
| in the previous environment, the expected value of their
| contribution in the current environment is very low. Possibly
| negative after considering the drain on the maintainer(s).
| milesvp wrote:
| I think the author is missing a key point in that software is
| vastly more complex than it was in the 90's. The few times I've
| tried to contribute to open source, I spent more time trying to
| convince projects that my pull requests fixed the problem without
| causing other issues. And this is largely because my fixes tend
| to fix integration problems I had with the software. These
| weren't small changes that could be unit tested, and setting up
| test repro steps were non trivial. I don't blame maintainers for
| being slow to accept these kinds of fixes, when the bugs are
| likely to effect a small minority of users. 30 years ago you
| could look at a patch and at least reason about it's efficacy,
| now you have to have some idea about supporting ecosystems, and
| not just libraries you're already using.
| StillBored wrote:
| So many of these projects are "mature" which means for many of
| them there is a risk to accepting random pull requests. In the
| past a growing project tended to take them without to much
| worry under the assumption that if a patch broke something it
| would get fixed. Now there is a fear of the effort required to
| dig through the mountains of code to "support" someone who is
| screaming about the code breaking.
| jdxcode wrote:
| I agree. In my experience maintaining, the work validating a PR
| is substantially more than writing the initial code as well.
| There is also a significant maintenance cost that falls on the
| maintainer after the code has shipped.
|
| In other words, even if your contribution is perfect, it's
| still probably putting more work on the maintainer than you did
| yourself.
| Jugurtha wrote:
| > _If you go back to the 90s, when we first figured out how
| communities built software, it took a lot of work to use the
| internet. It wasn't fast or easy, but that made it special: it
| meant that everyone on the internet cared about it, a lot. You
| were really committed to being there. Online communities back
| then were like a federation of villages; each one had its own
| culture, its own customs, and its own values. The open source
| community was like that too, and remained so for a long time._
|
| > _In these kinds of environments, attracting more users really
| did advance open source projects, because the costs were usually
| worth it. When a new member joined a community, they were
| probably serious about it. There weren't many "tourists" back
| then, so there was a real environment of camaraderie. Existing
| users were happy to onboard you and teach you things, because
| their effort would likely pay off as a good investment._
|
| > _Since community members joined slowly and stuck around, there
| was a lot of trust and shared context in the group. Every
| community had a different way of working, so there was a fair
| amount of friction preventing users from jumping around or
| "surfing" from project to project. Groups could preserve and
| maintain their collective motivation to keep shipping; they
| weren't getting paid, so that motivation was everything._
|
| > _It sounds pretty idyllic, and for many users back then, it
| was. As the internet grew more popular, the old timers reliably
| complained every September as a new crop of college freshmen
| gained access for the first time, not knowing any of the social
| conventions. AOL opened the floodgates in 1993, which Usenet
| bitterly declared "Eternal September", and the internet veterans
| have been complaining about it since._
|
| > _We know what happened next with online content. The tapestry
| of forums and newsgroups that made up the early internet
| flourished for a while, but in the 2000s an invasive species
| arrived: the platforms. The platforms made it so easy to create,
| share, distribute and discover that everyone joined them,
| smushing everything together into common, user-friendly formats
| without the local context or nuance of the smaller groups._
|
| It seems to be an: Oh, let me tell you about the good ole' days
| when the internet sucked so badly that it amplified natural
| selection and all the twenty people on it could hack on the Linux
| kernel and the output was amazing. Now that any peasant can get
| on the information highway and participate, everything is ruined.
| awkward wrote:
| The story doesn't have to be about how the old days with the
| old barriers to entry was the way. What it's definitely about
| is the flaws and problems in the current way, where platforms
| collect from continuous posting and participants collect from
| long tail effects.
| agumonkey wrote:
| I can't help but to feel just like the author of this article.
|
| I'm vastly in favor of taxing and hurdles as natural filters.
| Mainstream spoils everything (~almost). You end up having
| people not really into things, endless debates about side
| features, about how to organize the projects (inclusiveness,
| code of conducts, tooling), scandals and less about the passion
| of doing the thing.
|
| I'm often amazed at the difference in pacing and communication
| on Mailing Lists. It's slower but denser.
| deckard1 wrote:
| Drama has always surrounded popular projects.
|
| Anyone remember that Andrew Tanenbaum/Linus Torvalds
| flamewar? That was in 1992. This debate reverberated
| throughout the entire 1990s.
|
| People didn't need Twitter to throw shade and cast doubts.
| Usenet was a perfectly fine medium for this.
|
| https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb.
| ..
|
| Remember Slashdot and the "Slashdot Effect"? Slashdot was
| pretty much a forum for FOSS. It was already mainstream. And
| this is 1998 or so. The GNOME team caused _massive_ drama
| when they started their campaign against Qt (and, thus, KDE)
| on Slashdot.
|
| And on that point, GNOME was a reactionary project. It was
| not started as a community of people coming together to
| create _good_ software. It simply wasn 't. I was there
| (mostly observing from the Gtk+/GIMP side at the horror
| show). Gnumeric was slapped together in like one day. It was
| pure 100% trash code. All that CORBA, ORBit, etc. stuff was
| tossed together. GNOME was a movement that feared KDE would
| beat them to the "Linux on the desktop", and their initial
| versions were designed to play catch-up with KDE's feature
| set. I can't overstate how shit early GNOME code was. And
| then they took to Slashdot to bash the less-than-free Qt
| because GNOME certainly wasn't winning on merit alone.
|
| The free software community has been a shitshow for as long
| as such a thing has existed. Go back to the homebrew movement
| and see how people reacted to Bill Gates selling proprietary
| software.
|
| https://en.wikipedia.org/wiki/Open_Letter_to_Hobbyists
| Jugurtha wrote:
| It's called nostalgia, and we pretty much all have that
| condition.
|
| There are some fields or scenes where I recall how it used to
| be magical, but I know my mind is playing with me.
|
| Many people think that it's too much, too many apps, too many
| people, too much complexity. Yes. That may be the case and
| this may not suit everyone, especially those who lived
| through a pretty magical period with the birth of the world
| wide Web, or BBS, or open source movement, or the free
| software movement. Yes, god damn, that has got to make
| someone nostalgic. However, all that is now is not 'just'
| ruining it. The Beatles are what they are because of all the
| people who've never been to their concerts who wish they had
| been, amplified by people who were there who thought Paul
| sucked at guitar at the time. People mostly are indifferent
| to shifts in the now, and only cling to the now when it
| becomes the good old days or when someone makes a documentary
| about it and we feel we belong special for belonging to
| something that is not anymore.
|
| This says much more about us, our desire to belong, to be
| special, than it says about what reality is or was. We can
| apply this to forums people thought sucked until they
| disappear and the memories kick in.
| agumonkey wrote:
| it's too much, not enough, and too many issues around
|
| I like more balanced meals in a way
|
| And it's a bit objective too. IRC, Mailing lists did a lot
| with few. Now you have to have discord/slack/zulip to .. do
| the same ? consider the average website bloat.
|
| It's not pure nostalgia (I can realize my biases a bit)
| Jugurtha wrote:
| I'm not being dismissive and I'm not reducing the whole
| piece. I still look for an IRC channel and a mailing list
| for something by default when I want to join something.
|
| The Python IRC channel and mailing lists are top notch,
| with lengthy debates and great advice. The excerpt sounds
| like what an old geezer, in the soul, would say. I
| recognize it because I sometimes catch myself thinking
| like that.
| StillBored wrote:
| In the 1990's, the only people using the software tended to be
| people capable of debugging the problems. Now due to maturity,
| code complexity, and the simple fact that there are a lot of
| "users" means that its a lot bigger deal if a random patch breaks
| something.
|
| Its the result of the success of the project more than anything.
| Now the maintainers have to start acting like real developers and
| do the difficult/unsexy parts of maintaining something rather
| than just hacking at the fun bits.
|
| It really points out that much of what people considered the
| strengths of the opensource model were illusions that evaporated
| when the ratio of users/developers got very large. That doesn't
| mean its not a valid model, only that its a mistake to think a
| project can both be successful and popular while simultaneously
| expecting everything to be done by volunteers.
| mywittyname wrote:
| Even with tools like github, which are supposed to make
| collaboration easier, it is still incredibly difficult to
| contribute meaningfully to an open source project.
|
| I actually had a job where I had the privilege of modifying an
| open source tool as part of my day-to-day job. Even there, I
| found it very difficult to give back to the project because the
| maintainers of the project weren't terribly interest in having or
| maintaining the enterprise-y, cloud-y features that I was
| implementing.
|
| It seems like most OSS projects have a single key contributor /
| BDFL who decides the direction of the project. Outside of
| financial incentives, it's hard to get groups of people moving in
| the same direction.
| TheHideout wrote:
| This reminds me of a book I enjoyed, Show Your Work.
| https://austinkleon.com/show-your-work/
| __jf__ wrote:
| "Find your fellow knuckleballer"
|
| He also did a SXSW talk about it:
| https://m.youtube.com/watch?v=m8v3jf8RVBk
| [deleted]
| fudged71 wrote:
| I thought this was going to be about the Maker Movement and how
| huge some of these channels have gotten on YouTube
| jrochkind1 wrote:
| > Something important changed between the 90s and today. If you
| look at most open source projects now, the distribution of who's
| doing the work versus who's simply there is skewed dramatically:
| it's common to see projects where 95% of the work is done by a
| nucleus of people, perhaps even a single developer, with a long
| tail of "contributors"
|
| Any evidence this has actually changed between the 90s and now?
|
| I have a strong suspicion that it's always been this way.
|
| There are exceptional projects where the work is more distributed
| (is Linux an example?), but my suspicion is that they were
| exceptional in the 90s and still are, and that all along most
| projects have this "dramatic skew" as described.
|
| For software of now, you can look at github. For software of the
| 90s, 2000s... I wonder if anyone has tried to research this?
|
| I definitely don't see any reason to assume it was different
| without evidence.
| z3rgl1ng wrote:
| +1, [Citation Needed].
| z3rgl1ng wrote:
| Christ, every reply to this thread is an anecdote.
|
| Please back up assertions with _some_ data point..
| bergie wrote:
| Totally anecdotal, but I feel open source projects were much
| more community oriented in the 90s and the 00s. But after that,
| it seems they're either driven by a company, or an individual.
| That would roughly conform to the article's timeline of GitHub
| adoption.
| jrochkind1 wrote:
| By "community-oriented", do you mean that the distribution of
| commits was such that more people were making more commits,
| instead of "95% of the work is done by a nucleus of people"?
|
| I'm not sure if those are the same thing, I'm just talking
| about the distribution of work.
| gowld wrote:
| Everything has more "individuals" now, since everyone can get
| a soapbox/megaphone, from YouTube to GitHub to Twitter to all
| the rest.
|
| And it's possible to monetize that work now, with ads and
| micro-patrons, which is a huge drain on free and open source,
| mitigated only (partially) by the increased ability for open
| sourcerers to collaborate and that nowadays we're drowing in
| software and don't really need much more new software.
|
| You don't need to join a team to get noticed (and on the ugly
| side, even though having a team helps, it's better for the
| Personal Brand to make that team invisible)
| nerdponx wrote:
| Counter-anecdote: most of the small open-source projects I
| use only have a small number of active contributors because
| there is a small number of people who actively try to
| contribute.
|
| Projects that stop accepting PRs tend to be pronounced "dead"
| after just a few months, but there isn't always someone
| able/willing to fork it and keep the project going.
|
| Maybe there are more projects to contribute to than before,
| so each project gets a smaller % of the "potential
| contributor" pool.
| coldtea wrote:
| > _Any evidence this has actually changed between the 90s and
| now?_
|
| Experience with the relevant communities (Gnome, KDE, and
| others, etc) in the 90s and 00s.
|
| One reason for the change since then is that nowadays most
| things are more feature complete so low hanging fruits are not
| there (higher cost to entry for newcomers and fewer things to
| do if you're not "up there" as a developer), plus you need to
| "compete" or "collaborate" with a number of paid developers
| from companies like RedHat who handle most of the project and
| steer its direction wherever the company likes.
|
| Plus FOSS just isn't as glamorous as it used to be:
|
| The year of "Linux of the Desktop" (which as a vision meant
| mass adoption of Linux to win over Windows in desktops and
| laptops, not the "but Linux is fine for desktop use today, I've
| used it for years" or "but billions of Android phones use Linux
| behind the scenes" we settle'd for) never came.
|
| "Big" companies stopped caring about Linux except as an server
| thing (e.g. we had Easel, Corel, and others competing for
| desktop Linux, even IBM and others had an interest, whereas VA
| Linux was one of the biggest IPO stories).
|
| There are much less stories about the sexiness of FOSS or some
| FOSS future, and hackers changing everything working together,
| etc, in mainstream (not industry) media, etc.
| gowld wrote:
| Linux on the "fleet" desktop almost happened (some companies
| and schools do it), but then webapps got big and ChromeOS
| swept in. Now the only reason to make a non-ChromeOS "webtop"
| fleet is if your organization is explicitly Google-free for
| competitive/legal/political reasons.
| nitrogen wrote:
| _For software of the 90s, 2000s_
|
| Check Sourceforge, Freshmeat.net archives, IRC, old anonymous
| FTP mirrors, etc.
| Spivak wrote:
| Users of software care about their own workflows, their pet-
| features, and the bugs they hit. Some are willing to put up the
| work to patch in those features or fix those bugs and upstream
| them. Fewer still are people who are invested enough to
| dedicate themselves to a project as a part-time job.
|
| I don't think this dynamic has changed since the dawn of open
| source.
| stonogo wrote:
| It used to be you could email a patch to someone and that patch
| would get reviewed and committed.
|
| Since then there has sprung up a fetish for bureaucratic
| process, and tooling has arisen to foster that, such that the
| barrier to entry is significantly higher now than it was in the
| 90s. All you needed was a text editor and an email account. Now
| you need accounts on whatever code forge is involved, and you
| didn't write enough unit tests, and you failed to properly
| format your pull request, and what do you mean you're not an
| expert in whatever version control we've adopted? This pull
| request sat in an open state because you didn't tag it
| appropriately. The CI system was updated and your code wasn't
| covered in the automated integration test, please resubmit
| after making minor punctuation changes in a metadata file.
|
| Over time, this stuff filters out contributors and leaves a
| core of people who are comfortable with the structure of the
| engineering process for that specific project. It's not a bad
| thing that engineering standards are higher, but it's no longer
| a world of people 'scratching an itch' -- there's yak shaving
| to be done, and the number of people willing to shave that yak
| has always been smaller than the number of people who are not.
|
| I don't think the author is right about things having been
| harder in the old days led to a higher proportion of the
| internet being qualified to contribute. I think it's much
| harder now to patch software upstream than it ever has been.
| throwaway2245 wrote:
| You could re-frame 'bureaucratic process' as 'expectation
| setting'.
|
| It also benefits the contributor to know what is expected of
| them. If you know that your contribution will be properly
| considered when it meets the outlined expectation, then it is
| easier to put in the effort to contribute.
| microtherion wrote:
| > It used to be you could email a patch to someone and that
| patch would get reviewed and committed.
|
| May I ask what communities you were involved in, and when?
|
| Even formatting patches so they could be reliably applied was
| a nontrivial matter. It was not uncommon for them to be
| applied manually (and sometimes faultily). Sometimes you
| would mail patches to maintainers directly, other times you
| would share them on mailing lists, where they would undergo a
| bit of "social review" (works for me!) and would or would not
| be applied.
|
| Some people just mailed entire modified files and expected
| maintainers to figure out the changes on their own.
|
| As for "committed", many maintainers may not even have used
| source code control (notably Linus didn't use any), and I
| can't recall a single project with publicly accessible
| repositories in the 1990s as opposed to tarball releases.
|
| > All you needed was a text editor and an email account. Now
| you need accounts on whatever code forge is involved [...]
|
| Getting an account on any of these code forges in 2020 is
| almost certainly much easier than getting an e-mail account
| at all in the early 1990s for many people.
|
| I don't agree with the author that contributing was easier in
| the 1990s. Generally, it involved a bit of a social process,
| trivial drive by fixes were not any more popular than today,
| there were coding standards to be observed (and not always
| written ones), in larger projects, you could expect to
| navigate some flame wars, and sometimes your contributions
| were rejected anyway because RMS decided to cancel your OS.
| tom_ wrote:
| Very much mirrors my experience. Github provides a very
| useful project-independent unified UI for drive-by patches
| and off-the-cuff issues. No more mailing lists or bug
| trackers to sign up for and manage!
|
| And it's also even got an integrated version control
| system, that 99.9% of projects then use, and it's one that
| makes it easy to version control a fork of your own as you
| work on any patches you might be making.
|
| Progress!
| nerdponx wrote:
| In my experience, bureaucracy is mostly uncorrelated with the
| willingness of a project to accept a PR from a new
| contributor.
|
| Homebrew has very strict contribution requirements but has a
| huge number of contributors and is generally easy to
| contribute to. Meanwhile there are lots of little projects
| that go dead for lack of interest by the sole maintainer in
| reviewing and merging patches.
|
| Also this:
|
| _Since then there has sprung up a fetish for bureaucratic
| process, and tooling has arisen to foster that, such that the
| barrier to entry is significantly higher now than it was in
| the 90s. All you needed was a text editor and an email
| account. Now you need accounts on whatever code forge is
| involved, and you didn 't write enough unit tests, and you
| failed to properly format your pull request, and what do you
| mean you're not an expert in whatever version control we've
| adopted? This pull request sat in an open state because you
| didn't tag it appropriately. The CI system was updated and
| your code wasn't covered in the automated integration test,
| please resubmit after making minor punctuation changes in a
| metadata file._
|
| Doesn't really make sense to me. How many projects have you
| actually had this problem with?
|
| _I don 't think the author is right about things having been
| harder in the old days led to a higher proportion of the
| internet being qualified to contribute. I think it's much
| harder now to patch software upstream than it ever has been._
|
| For some people, using Git and Github is a barrier to entry.
| For others, submitting a patch to a mailing list is a barrier
| to entry.
| ekiwi wrote:
| > It used to be you could email a patch to someone and that
| patch would get reviewed and committed.
|
| Yes, but 1990 is also when this study came out:
| https://ftp.cs.wisc.edu/par-distr-
| sys/technical_papers/fuzz....
|
| They find that a lot of UNIX tools could be easily crashed by
| generating random inputs. The quality of our most popular
| open source software has dramatically improved over the last
| 30 years.
| jdbernard wrote:
| Another component, I think, is the difference between being
| able to work on whatever you want vs. having to follow a
| roadmap dictated by project leadership. Other commenters have
| touched on this (pointing out the decline of community
| orientation, rise of corporate oversight, or the fading
| glamour, for example), but no one has identified it directly.
|
| The article points out that we collectively re-examined Brook's
| rule, going from "adding more engineers to a project makes it
| ship later" to "if you need to get more work done, go attract
| more contributors." I think the evidence shows it's more
| nuanced.
|
| If you have a large amount of potential tasks and a large pool
| of potential contributors, and little strong preference for
| which tasks get done (OSS in the 90's maybe) then highly self-
| motivated people can pick up work they find interesting or
| which are useful for them. You can then avoid the exponential
| explosion of communication/coordination overhead by empowering
| those individual contributors to make their own decisions about
| how that work should be done. This is how OSS can scale to
| hundreds of contributors.
|
| Once you introduce some sort of top-down planning that dictates
| which tasks are important, the blessed approaches, strict
| coding patterns etc. then you demotivate a large number of
| contributors who don't share the top-down priorities and you
| have to pay the exponential overhead cost of distributed
| coordination to enforce the top-down priorities.
___________________________________________________________________
(page generated 2021-01-26 23:00 UTC)