Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Open Source Programming

The Few, the Tired, the Open Source Coders (wired.com) 71

Posted by msmash from the closer-look dept.
Reader shanen shares a report (and offers this commentary): When the open source concept emerged in the '90s, it was conceived as a bold new form of communal labor: digital barn raisings. If you made your code open source, dozens or even hundreds of programmers would chip in to improve it. Many hands would make light work. Everyone would feel ownership. Now, it's true that open source has, overall, been a wild success. Every startup, when creating its own software services or products, relies on open source software from folks like Jacob Thornton: open source web-server code, open source neural-net code. But, with the exception of some big projects -- like Linux -- the labor involved isn't particularly communal. Most are like Bootstrap, where the majority of the work landed on a tiny team of people. Recently, Nadia Eghbal -- the head of writer experience at the email newsletter platform Substack -- published Working in Public, a fascinating book for which she spoke to hundreds of open source coders. She pinpointed the change I'm describing here. No matter how hard the programmers worked, most "still felt underwater in some shape or form," Eghbal told me.

Why didn't the barn-raising model pan out? As Eghbal notes, it's partly that the random folks who pitch in make only very small contributions, like fixing a bug. Making and remaking code requires a lot of high-level synthesis -- which, as it turns out, is hard to break into little pieces. It lives best in the heads of a small number of people. Yet those poor top-level coders still need to respond to the smaller contributions (to say nothing of requests for help or reams of abuse). Their burdens, Eghbal realized, felt like those of YouTubers or Instagram influencers who feel overwhelmed by their ardent fan bases -- but without the huge, ad-based remuneration. Sometimes open source coders simply walk away: Let someone else deal with this crap. Studies suggest that about 9.5 percent of all open source code is abandoned, and a quarter is probably close to being so. This can be dangerous: If code isn't regularly updated, it risks causing havoc if someone later relies on it. Worse, abandoned code can be hijacked for ill use. Two years ago, the pseudonymous coder right9ctrl took over a piece of open source code that was used by bitcoin firms -- and then rewrote it to try to steal cryptocurrency.
This discussion has been archived. No new comments can be posted.

The Few, the Tired, the Open Source Coders More

The Few, the Tired, the Open Source Coders

Comments Filter:

  • OS got CoCed up (Score:3, Insightful)

    by sinij ( 911942 ) on Friday November 20, 2020 @03:36PM (#60747850)
    How do you like them Code of Conducts now?

    • Re:OS got CoCed up (Score:5, Interesting)

      by AmiMoJo ( 196126 ) on Friday November 20, 2020 @04:03PM (#60747986) Homepage Journal

      The code of conduct has been a boon for open source developers like me. It used to be much worse, people coming and making ridiculous demands on your time, insulting you, trolling when you didn't give them what you wanted. Most of those people seem to have given up now. Just having a code of conduct file in the repo is like a scarecrow.

      Even so it's still not easy. You get well meaning people making genuine contributions and then feel like you are letting them down because you don't have to time to review their code, to test it and merge it. I submitted a patch for libusb a few years ago, it got merged after a year and a half and a month ago they asked if my problem was fixed... I haven't responded yet because I need to clear a space, get the development hardware out of the box and try to remember exactly what I need to do to test it. I'll get around to it, one day...

    • Re:OS got CoCed up (Score:4, Informative)

      by AleRunner ( 4556245 ) on Friday November 20, 2020 @04:06PM (#60747992)

      There's nothing wrong with a "Code of Conduct" as such, it's just another name for a code of ethics. . The Association of Computing Machinery [acm.org] code of ethics addresses a whole load of really important things like privacy, confidentiality, honesty and code quality.

      If you have an important piece of software and you either do not have a code of conduct or your code of conduct does not address the need to mitigate and / or disclose security vulnerabilities then that is a serious oversight since you can have developers working on your project who are getting benefit from finding out about security vulnerabilities and not doing anything about them. Let's see what the ACM says about this

      Computing professionals should also take steps to ensure parties affected by data breaches are notified in a timely and clear manner, providing appropriate guidance and remediation.

      In fact, having a code of conduct which did not mention this, or requirements for quality standards would be worse than not having a code of conduct at all. That would imply that you did not care about causing harm to your users.

      Perhaps you were complaining about codes of conduct which are unacceptably badly written?

      • Re:OS got CoCed up (Score:4, Insightful)

        by Entrope ( 68843 ) on Friday November 20, 2020 @04:23PM (#60748116) Homepage

        Codes of conduct are inherently less about what you do than how you do it. That's why they're called codes of conduct rather than codes of ethics. People who prioritize CoCs over actual work put the cart before the horse.

        • That's been my experience, too. The CoC moaners aren't coders: they are shit talkers. Coders want to code. SJW's want to bitch and control others who refuse to onboard their "shared values" which aren't actually shared. You see the same instinct when folks talk about AI having the racial bias coded in by evil conservative coders who refuse to embrace their CoC urge. They hate the idea that "those coders" might influence a back-end system to act in a way they thought was not-leftist-enough.

        • Fortunately those writing those for open source projects are not programmers and do not take away programmers time, only their own. And the enforcement is usually as extremely vanishing as the breaches of good conduct.

          The problem is worse with the war on words, but that seems limited to the US at moment, and even then are just simple search and replace nonsense.

    • Times change and so does culture. Feel free to create your own CoC free fork.

      • You're missing the point. Coders leave because it's all so disgusting and just don't want to have to be confronted with that crap at all. Then FOSS projects lose help and the interest of the skilled help they need. Coders typically don't have much tolerance for political ass-wrangling while trying to get shit done.
        • Coders age out. What seemed important and exciting 35 years ago looks fugly and boring 35 years later. Youth nigh be wasted on the young, retirement is the pay-off for getting old. Helps to compensate for the aches and pains.

          Tried to use my laptop with a 26" screen and 64-point font. Can't do it, so stuck with my phone jammed in my face. And retinal surgery and IOL implants aren't emergencies, because covid doesn't care, so probably another 2 years of being legalized blind, so fuck it. Time to enjoy retir

          • I've got macular degeneration. I'll be right behind you in a few years. I agree with you about aging out, too. However, some of those badasses write some extremely important code in their "waning years". They might be older and more crotchety, but they are are also super slick coders by that point, usually.

  • Undo Focus on super large projects (Score:3)

    by nevermindme ( 912672 ) on Friday November 20, 2020 @03:40PM (#60747866)
    The best apps tend to remain tiny and limited in scope. I rather spend some spare time making a few pull entries to select edge case functions in nmap or a Wireshark filter.

    • Re: (Score:2)

      by shanen ( 462549 )

      I think you're describing a different problem with focus there. Small projects are easy to complete with some degree of success because that's the limit of what one person can focus on. Even the large projects had to start with a small focused vision.

      Anyway, the editor rejected my commentary on the topic, so I feel like I shouldn't say more. Apparently nothing salvageable there? Should I have mentioned that programming is hard work?

    • I see two sorts of programmers. One can manage a small program in detail. It can be tens of thousands lines long, but not millions. I am one of these; you may be too. Then there are others who can happily stitch together lots of different pieces of code, and make something huge out of this. I sometimes can't even read their code: it is all classes and wrappers and producers and factories, and hard to find what actually does something. Or, you have the data you want *over here* but you can't see how to get i

  • Mozilla and Wikimedia are swimming in cash yet have very bad products. Mozilla is only getting the money to stop Google’s anti trust lawsuits anyway.

  • Space Station 13 is the poster child for this (Score:4, Insightful)

    by WarlockD ( 623872 ) on Friday November 20, 2020 @03:47PM (#60747916)
    I have only been coding there for a year (tgstation fork) and I can tell you just brows the forks (ftl station, unitstation, etc) to see those long time coders go away and they die hard. Its the head coders that keep us on a a path (No feature November so its bug fixes woo.) and still respect all the little guys who fix the small issues that save us.

    But the fact is that burnout is the real reason. Monetary gain is all fine and dandy, but when your designing a game system from scratch, even if its reviewed by 8 people, the processes is mind-numbingly heartbreaking as well as stressful. A perfect example is xeno. The idea is that science can breed slimes that have different properties and can be made into materials or just for the luls. The problem is that with the 10 or so slime colors we have only 4 have fleshed out mechanics and the running curse is that once you finish a slime color you never touch SS13 again

    I can rant for days on how we don't control the back end. How Github killed our repo and deforked eveyone else in the process because we had "retard" in the comments. Or the constant ddos or trolls. Or when you get your own pr hard killed for reasons that seem stupid at the time. You have to love a project to keep going no matter how bad the trash fire gets. Because at the end of the day, you are proud of that fire and want to show it off to the world.

    • Re:Space Station 13 is the poster child for this (Score:5, Insightful)

      by AmiMoJo ( 196126 ) on Friday November 20, 2020 @04:35PM (#60748182) Homepage Journal

      When a project starts small it's easy to contribute lots of code to but the individual or team probably doesn't have a lot of time to handle pull requests or track down bugs that only affect other people's configurations.

      When it gets big the barrier to entry for working on it gets much higher. You can't just contribute code, there is a huge amount to learn first. The quality of patches starts to deteriorate, and I'll admit I've been guilty of that. Had an SMS/HTTP gateway library that was being used in a project at work which didn't support some particular encoding that was used in the Philippines so I added support, but being a work thing I had limited time so did the minimum possible (receive only, no test cases) to get it working. Of course I submitted the patch as required by the licence and of course they asked me to do a proper job and not half arse it. I had to apologise and explain that I couldn't, and that was that.

      • Amen brother. Just look at the repo we got. Its a mash of byond dm script, jQuery, reacts baby cousin inferno. We HAVE to use automated built tools though GitHub because we just don't have the time to verify a lot of the even simple pulls. This means webpacking each build and having the person submitting repack it every time we do a merge just so Travis is happy. Though I think we don't use Travis anymore. Honestly the real problem is everyone has their own standards and ways of doing things. No one

  • So ... (Score:3)

    by fahrbot-bot ( 874524 ) on Friday November 20, 2020 @03:52PM (#60747938)

    The Few, the Tired, the Open Source Coders

    Would this make proud Java programmers "jarheads"?

  • Comment removed based on user account deletion

    • That has nothing to do with a code of conduct. The biggest contributors are going to start small. There is a difficulty in quickly parsing the difference between an initial commit from someone who will seriously grow and a dilettante who will bail in minutes.

  • Of course... (Score:4, Insightful)

    by enriquevagu ( 1026480 ) on Friday November 20, 2020 @04:04PM (#60747988)

    Anyone can submit a patch to correct a bug found in an application. However, not anyone can specify the application architecture, or decide where it wants it to go.

    Applications belong to the primary developers, who make relevant high-level decisions. Presuming that open-sourcing a code would outsource this complex decision-making job is naïve.

    • RTEMS.org has been around as an open source project since the early 90s and I agree with you. It is the responsibility of the core developers to be architects, build the basic structure, and add enough value to that where others can use it but still have clear areas to contribute.

      But that isn't all that is required to get contributions. You have to have low barrier to entry for both users and new developers, be nice and help them, be responsive to reviewing and merging, and have decent documentation. You ha

  • Neckbeards (Score:3, Interesting)

    by solidraven ( 1633185 ) on Friday November 20, 2020 @04:17PM (#60748078)
    Simultaneously, on top of the SJWs everyone is highlighting, neckbeards still are a serious issue in FOSS development. I've been on more than a few projects where I just said screw it (a few ten thousand lines of contribution in) and quit because I got fed up with some arrogant jerk who thinks he's a gift to the world. It's one thing when someone isn't complying with the architecture that was put forth in the development documentation, I agree that needs to be pointed out. But it's a whole other when you start picking on folks who joined the team over the last few months because they dare to put some of their own time into expanding the feature set they actually need themselves. I literally got berated for adding a well-received feature to a major FOSS project a couple of years ago, a feature which was on the wish list of the development tracker I might add. The only reason it made it in was because the neckbeard only noticed it after a few patches, he couldn't pull the plug on it anymore without also deleting other people's "approved" work - which made use of some of the support functions I wrote. So yeah, since then I've stopped contributing to projects and I just spend time on things that I get paid for instead.
    • Usually you should try to understand the architecture of the project before adding to it.

      The neckbeard probably is better than you.
      • As I clearly implied, I understood the architecture and proceeded as stated in the documentation. And I should also add a few more details:
        - The feature is still in there without any rewrites or patches applied to it.
        - What actually happened was that he probably didn't understand the math behind the optimization algorithms that were on the project wish list. He felt hurt in his pride that someone implemented it before he figured out how to do it, since he had been boasting about having a working implem
        • It sounds like your ego is the one that was hurt.

          • Re: (Score:2)

            by radl33t ( 900691 )
            , which seems like a reasonable reaction to the situation.

          • Re: (Score:2)

            by malkavian ( 9512 )

            His sense of professionalism was tweaked, and also, correctly identified a breach of ethics.. That kind of behaviour has had me look askance at people before, and if they were serious in that approach, I simply took myself elsewhere and built better things for people that appreciated it more.
            I now get to build some very interesting things for some very interesting people and thoroughly enjoy it. All because I shrugged, and left the irritating people to get on with things their own way.

    • Re: (Score:2)

      by ahodgson ( 74077 )

      Sadly, most people are hard to work with at least some of the time. Making teams work is hard. There's a reason companies have management.

      • This is true, though in a corporate environment it often only works because the manager is a bigger jerk, so the whole team gets together to make the manager's life harder.

  • Instead of small modules with a good interface that do one thing and do it right, we have disgusting abominations like office suites and browsers and JDK etc.

    Programmed right, any small coder could contribute even to the core microkernel module.

    In my experience, if you cannot code it up in a single day, fix all the bugs in a second day, and fully document it, in a third day, it's too big, you need to throw it away and make something new from scratch.

  • Bootstrap was a corporate project. That "small team" that did most of it was getting paid by their corporate sponsors. Not only that, but the purpose of it was to have a spyrus to infect common people's webpages through 3rd party sideload.

  • The summary outlines the cases where this works: When a small team keeps the whole thing in their heads.

    Github's full of JS "Popularity" b/c NPM has tiny libraries. Those tiny pieces are easy for a small group to maintain and easy to be replaced if they lose interest (Ex: Underscore --> Lodash).

    With more intermediate interfaces, open source could bridge the gaps between the interfaces with small libs. The 100s of possible intermediate interfaces between 2 points risks duplication, but that's OK.

    Ex: Grap

  • Open Source is NOT "socialism" but... (Score:4, Insightful)

    by tiqui ( 1024021 ) on Friday November 20, 2020 @06:50PM (#60748724)

    it suffers from some of the basic problems and for a similar basic reason: Human Nature which tends to produce the Tragedy of the commons [wikipedia.org].

    Early on in the open source movement, people like Bill Gates tried to attack it by claiming it was "socialist" and "anti-capitalist" - many here should remember that it was a real thing that people with businesses selling close source software thought they could influence average people and politicians to oppose it by tying to Karl Marxs. That tie never existed except superficially; People were indeed working at their ability level and giving the results away - BUT there was never any government force involved.

    We're mostly past the point of people objecting to open source code on those [quasi-polititcal] grounds, but it does not fix the underlying commons issue, which has in some ways become worse as companies have embraced this code for their products. It use to be the case that open source coders would work hard and see lots of people using their code with no compensation, people involved could get moral satisfaction feeling that they were helping others with their skills. Now, however, many such coders see big companies using that code to make piles of cash with nary a nod to the coders - that's less morally satisfying and will tend to amplify the negative effects of the Tragedy of the Commons.

    There are problems here that have never been resolved and which will act as a natural governor of the rate and quality of Open Source code development. I'd love to offer a possible solution, but it'll take somebody wiser than I am to come up with one that truly works.

  • With training this could be a solution for how to support the many people who are unemployed.

  • The merits and values of open source lauded here - ... as a bold new form of communal labor: digital barn raisings. If you made your code open source, dozens or even hundreds of programmers would chip in to improve it. Many hands would make light work. Everyone would feel ownership... were sought in 1959 when IBM started SHARE. [wikipedia.org]

  • Would having sort a patreon model for OSS help prevent the abandonment?
    The money then comes to the actual developers...
  • A lot of great apps would require a good amount of effort and knowledge. Not everyone here has the time and patience to do so. This is why you need to hire professionals when you need an app. My choice was a https://www.avenga.com/industr... [avenga.com] , so it's time for your choice too.

Slashdot Top Deals

You knew the job was dangerous when you took it, Fred. -- Superchicken

Close