Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Open Source Businesses The Almighty Buck Technology

The Complicated Economy of Open Source Software (vice.com) 96

An excerpt from a report, which looks at the complicated business of funding open source software development: On the surface, the open source software community has never been better. Companies and governments are adopting open source software at rates that would've been unfathomable 20 years ago, and a whole new generation of programmers are cutting their teeth on developing software in plain sight and making it freely available for anyone to use. Go a little deeper, however, and the cracks start to show. The ascendancy of open source has placed a mounting burden on the maintainers of popular software, who now handle more bug reports, feature requests, code reviews, and code commits than ever before.

At the same time, open source developers must also deal with an influx of corporate users who are unfamiliar with community norms when it comes to producing and consuming open source software. This leads to developer burnout and a growing feeling of resentment toward the companies that rely on free labor to produce software that is folded into products and sold back to consumers for huge profits. From this perspective, Heartbleed wasn't an isolated example of developer burnout and lack of funding, but an outgrowth of a systemic disease that had been festering in the open source software community for years. Identifying the symptoms and causes of this disease was the easy part; finding a cure is more difficult.
Further reading: How Does Heartbleed Alter the 'Open Source Is Safer' Discussion?
This discussion has been archived. No new comments can be posted.

The Complicated Economy of Open Source Software

Comments Filter:
  • by sa666_666 ( 924613 ) on Sunday February 17, 2019 @01:12PM (#58135370)

    I've been working on a project for almost 20 years at this point, and I definitely feel the same as what's reported here. As the project has gotten more popular and more users come on board, there is now much more demand on our team. And some companies have noticed the usefulness of the project and used it in commercial products. Not that I'm against that (as that's what the GPL basically encourages), but it would be nice at times if there was more contributions back from those that benefit from it.

    And I don't necessarily mean money either. Extra help in coding, testing, etc would be nice too. But I suspect that people get used to a product being free, and then asking for anything more once it becomes popular is out of the question for them. But in the long run, it really leads to developer burnout, as more people want more and more, and can't (or won't) contribute. I know I am personally feeling the burden and looking at burnout soon.

    Anyway, long story short; I can sympathize with developers in a similar situation.

    • I got user burnout, after having the bugs I reported either brushed away or marked WONTFIX. There's only so much of being resisted you can take before rage quitting the whole thing.
      • I got user burnout, after having the bugs I reported either brushed away or marked WONTFIX. There's only so much of being resisted you can take before rage quitting the whole thing.

        Yes, unfortunately that is a valid complaint too. I try not to do it personally, but I can see that if a developer is approaching burnout then they can resort to doing this. And it's then a self-perpetuating spiral that usually ends badly.

        • Is Open Souece a job or a hobby. Why worry about a spiral which primarily impacts businesses who don't want to allocate resources towards anything. Cut off the leeches and go back to enjoying the hobby. If it is a job, make sure you get paid, do like New York and evaluate the entire cost and be willing to say no. User burnout is another term for giving abusers the shaft. You want something done, you make it worth my while, or I will simply go back to spending my free time doing what I enjoy.
      • Re: (Score:2, Interesting)

        by Anonymous Coward

        I got user burnout, after having the bugs I reported either brushed away or marked WONTFIX.

        We need another status field in OSS bug trackers. Something like WILLFIXFOR_???$.

        • Gave some bug fixes back to a GNU project that we used on VMS. It lasted one release and then Stallman changed it seemingly to match the GNU style better but without actually knowing how it worked on VMS it was broken again. So at that point I just patched it without sharing the bug fix back again.

    • Use of open source covers a lot of cases. I have known startups that just copy and paste open source code, not even bothering to retain copyright notices, or even bothering to find out which open source solution would be best. The company often does not even know this is happening if development is done by a lot of mediocre devs that don't even communicate with each other much less to management. I see a lot of FreeBSD stuff littered about in products, and while this is generally very corporate friendly t

      • by bosef1 ( 208943 )

        Other problems are legal issues if I'm I make an improvement to open-source software on company time. First I need approval from the company to release work that we did for some project. If it's just a patch, getting the approval is not too hard, but it has to be done every time. Then I need legal approval actually release the patch back to the public, since open source means it's going out to everyone.

    • have you noticed a trend of dependency infiltration? I think it's because people want to have projects depend on their package so they can get a job due to having proven expertise.

      My theory is that for this reason a lot of packages in npm for example(and more and more on gradle) depend on other packages and get code submitted to make them depend on _more_ packages not _less_ packages, to the point where package dependencies are inserted just for things that need 3 lines of code to not be dependent on said e

  • by reanjr ( 588767 ) on Sunday February 17, 2019 @01:25PM (#58135434) Homepage

    "I thank you for your feedback, but I wanted to let you know this project is not actively maintained. This is a hobby project for which I do not get paid, and unfortunately I do not have the time to address all the feedback it receives. If you'd like to contact me about paid support or services, please send an email to..."

    Setup an autoresponder. Burnout is stupid.

    • Not every good coder is adept at human relations. I know, crazy talk.

      cf. "Education".

    • I've seen a few open source projects with a roadmap and the new upcoming/requested features and a donate button next to each one. Once a feature hits a threshold, they start developing it.

      It's a decent model, I'd be curious how GitHub etc helps to maintain this environment though. I imagine GitHub will turn into a kickstarter-esque platform for open source.

      • by tepples ( 727027 )

        I'm interested in adopting something like this for my own free software projects. Have the projects to which you refer made the software behind their pledge forms available as free software?

      • https://issuehunt.io/ [issuehunt.io] is a site which enables one to place bounties on Github issues.

        BountySource https://www.bountysource.com/ [bountysource.com] is a similar bounty system, which can front-end a variety of trackers including bugzilla and Github.

      • by AmiMoJo ( 196126 )

        I did a bit of paid development on some open source projects I made once, long ago. Decided to stop accepting any money though, because the amount people are willing to pay is never enough to let me quit my job or make it worth doing in my free time. Once you accept their money there is an obligation.

  • by Anonymous Coward

    The summary mentions that the corporate world doesn't understand the OSS norms. Just as likely, in my opinion, the OSS volunteers don't have a good understanding of the corporate participants. We all appreciate OSS volunteers and the wonderful software they create. That said, it should be no surprise to anyone, least of which the person who put the license on the software, that corporations are going to do anything lawful they can to make money. If that means creating terrible patches and not integrating wi

    • If that means creating terrible patches and not integrating with the flow of the OSS project itself, they may do that... The choice may be to attempt to get changes harmonized with the community or just publish whatever they come up with at the end. I suspect that there's a latent annoyance about this particular thing coming from the OSS volunteers. But ... you can't be surprised that they're not doing a good job of helping you merge them into the mainline. They're doing the least they can get away with.

      Except, they're missing out on some of the benefits by doing that. If they get their patches into mainline more easily, it's more likely that the next few releases will have their patches in them, and they won't have to keep updating their patches for the newer versions. Even more so if they contribute a unit test along with the patch - then they can have the comfort of knowing that their special case will be fixed for all time!

      Because companies are focused on the short term benefits, they are losing out on

  • Idea: Tax Amazon at, say, a tenth the rate I pay, then provide grants to the open source projects they are using for free.

    Society solved this kind of problem long ago, we have just forgotten the solutions. Treat open source software as the infrastructure that it is.
    • by Kjella ( 173770 )

      Idea: Tax Amazon at, say, a tenth the rate I pay, then provide grants to the open source projects they are using for free.

      How does that work when anyone can fork it? Oh we're not using OpenSSL, we did a search and replace so it's now AmazonSSL. Could Linus lord over all the money paid to Linux in perpetuity as benevolent dictator for life? Open source is not a democracy, it's a grab bag of code anyone can assemble into a product. The moment you start creating some form of royalties and owe the people who wrote it something you'll have all sorts of crazy fights for control and who actually contributed, like do you want to distr

      • by Mandrel ( 765308 )

        The moment you start creating some form of royalties and owe the people who wrote it something you'll have all sorts of crazy fights for control and who actually contributed, like do you want to distribute it by lines of code? Does it go back to every author in the tree?

        Yes, there is a licence [devwheels.com] where licence fees are propagated back to every package in the fork tree. There can also be a negotiated and registered share given to each developer within a package.

        You are right that _ [youtube.com], but _ [youtube.com]

      • by dryeo ( 100693 )

        Could do it like the arts in some countries, basically grants to interesting projects.
        Here, we have the National Film Board, https://www.nfb.ca/ [www.nfb.ca] who I see are proud of their 75th Oscar nomination and put out some good stuff financed by taxes.
        It's not perfect and you would get some shit projects mixed in with good ones.

      • This is one of the best cases that I see for a Universal Basic Income (UBI). Although most on the right think recipients of 'free' money wouldn't work, we don't have the data to support that supposition. Sure some people wouldn't work, but some would contribute their time to things like OSS without needing to worry about working a 'real' job for basic survival.

        If anyone wants to read more about this, the book "Trekonomics" has made a good case for how a society could be built with this in mind using some re
  • by bjdevil66 ( 583941 ) on Sunday February 17, 2019 @02:51PM (#58135788)

    Just one dev's opinion, but whether they're paid or not isn't the biggest issue. It's developer and community involvement - with devs ACTIVELY working on fixes, regardless of compensation (money, pride, prestige, etc.)

    And that doesn't mean the original creator/author and one other person/spouse/friend. This means a minimum of 6-10 devs that are actively working on it. When one can't respond, another can pick up the slack.

    End users turn their backs on projects that get the, "I'm too busy to do this," self-defense treatment from overworked developers/maintainers. That kills trust, which in turn kills the community of users and shrinks the possible pool of other devs who will bother to offer help.

    (Worse yet, the "I'm too busy devs," sometimes ghost their own project outright - while retaining the keys to the project and keep others from taking over or even applying patches. For example, I've seen this in the Drupal community many times (abandoned add-ons/modules/themes with years of no new releases with fixes despite the list of offered (and community reviewed) patches that rot on the vine). Git forks and such can help alleviate some of this, but It is a real PITA having to recompile patches into increasingly fragile build processes and maintain them ourselves when a simple release of control over the project when it's been abandoned for a certain period of time - allowing for new releases - would fix the problem.)

    Advice to OSS devs: 1) Be kind to contributors - even bug reporters. They just don't understand. 2) Don't waste time engaging jerks. Shun them. 3) Accept good help when offered, and KINDLY reject bad help. 4) Ask for compensation when necessary (for requests that don't really help the project or are one-off features). 5) Give up control ASAP when you're "done". Don't strangle your baby by holding on too long. 6) Commit to warning end users if the project is going to be shut down. Not doing this is devastating to popular project end users.

    Advice to all end users:
    1) Don't be a community leech! Donate in relation to how much you use a project.
    2) Don't just have a problem -- try to have a solution. You'll get back what you put into it.

    If you're an individual end user:
    a) Be kind and professional in your requests and effusive (but short) in your thanks for anything done (even a WONTFIX).
    b) Help out a little wherever you can (even simple, end-user friendly documentation for non-brainiacs; Almost all devs can use a heaping helping of help on.)

    If you're an organization with a budget:
    a) Donate any resources when possible to help it keep going. ($$$ is good, in-house dev hours is better, and both is best.)
    b) Know when to get out - usually when the community leaders disappear and the FIRST sign of tickets not being responded to. Jumping too early hurts your org, but waiting too long is even worse.

    • 1. Be kind to all contributors - even bug reporters that are wrong or uninformed. . They just don't understand.

    • by Anonymous Coward

      Hating on users by calling them "leaches" for following the contract terms is caustic and harmful to the community.

      If you don't want to share, don't share.

      If you want to control the actions of people using your software, don't use a license that respects their Freedom.

      If you used a license that does respect their Freedom, and then you find yourself feeling negative emotions about how they use it, stop your whining and meditate about your desire to control people to whom you promised Freedom.

      • Hating on users by calling them "leaches" for following the contract terms is caustic and harmful to the community.

        If you don't want to share, don't share.

        What's wrong with wanting to share, but sometimes wanting a little quid pro quo too? Are you following the absolute letter of the licensing by not doing anything in return? Yes. Are you following the intent? No, probably not. While there's no strict obligation to do anything, if you like the project and would like to see it continue, then perhaps (even for your own self-interest) you might consider doing something about it. A bug report, code contribution, small monetary contribution, etc. Hell, even

    • by Kjella ( 173770 )

      And that doesn't mean the original creator/author and one other person/spouse/friend. This means a minimum of 6-10 devs that are actively working on it. (...)

      So only 6+ man teams should be allowed to make open source projects? It drops from 6 to 5, they should pack up and go home? Talk about gatekeeping. Projects die when the number of maintainers go from 1 to 0, because there's nobody willing to take over. Yeah the community might make a fix when they have an itch to scratch, but nobody wants to reboot the project and deal with other people's wants and needs. Some kind of "auto-abandoning" would only be used by malware bots to take over and make infected softwa

    • In case you weren't aware, Drupal has well-documented procedures for reporting and/or taking over abandoned projects:

      https://www.drupal.org/node/25... [drupal.org]

  • Topic really touches a nerve for me, but I'm not going to write a novel-length contribution for Slashdot. Minimal background: My experiences with OSS and earlier forms goes back 3 or 4 decades and I think the potential remains unrealized on both sides. Both the programmers and the users have been let down, and I think the underlying problem is the money. No shit, Sherlock. Economics is about money and the overwhelming money is elsewhere.

    As a recovering programmer, let me focus on that side: Why should progr

  • Part of the attraction for OSS over proprietary software is the possibility of (competitive) contracting out support. Outside of RedHat for Linux, where are the support shops? I've worked on many (large) projects where they would be happy to let a contract for product support, but we couldn't find anyone to contract with. The expectation would be that we'd pay someone to fix bugs that got reported (with priority for those bugs we reported as significant), while contributing those fixes back to the OSS p

  • I tried for 20 years (since before university) with various project and means, extremely difficult to get people to pay for open source, support, documentation, donate, you name it. My latest expedient is YouTube videos to finance Open Source work: https://www.youtube.com/user/r... [youtube.com] I'm at $3 a day, :-/
  • I've been in meetings where a choice of technology comes down to free VS non-free, and free wins almost every time. They are sometimes willing to pay something for "support", but not much. As for "giving back", some companies prohibit their employees from contributing code to anything.

    So open source is great for the consumers of it, but less great for the providers and their commercial competitors.

  • I used to be a fairly prolific FOSS author and contributor. After many bad experiences with corporate leech asshattery and the general precariousness and impecunity of life as a Free Software developer, I said "never again".

    Now I still want to write Free-like-freedom software that any human being can use and share. But I am absolutely unwilling to give anything, even a steaming bucket of my own turds, for free to the capitalist dogs and their corporate cancers.

    Unfortunately there is no Free Software license

    • Unfortunately there is no Free Software license that distinguishes between human persons and corporate legal fiction "persons". I've been wondering what it would take to modify the GPL or BSD licenses to support this distinction in a way that would be upheld by the courts. Maybe call them HGPL and HBSD, the H standing for "human".

      I bet there are clauses of Creative Commons licenses [creativecommons.org] that do what you want. CC BY-NC-SA looks applicable, or possibly CC BY-NC-ND.

  • Software is software, whether Open Source or Commercial. I tried explaining to a peer that a given commercial product was a heavy user of OSS. The peer said that was a flaw because OSS is totally unsupported...so we should go with a separate product that is totally supported by commercial software.

    There are many OSS products that have a corporate license model in place that bridges the divide between the two. In the case above, the product using OSS invests in the technologies it needs, regardless of whethe

"If it ain't broke, don't fix it." - Bert Lantz

Working...