I don't see the relevance. Open source developers need not be burning themselves out, they can just choose to work on what they want.
If a big company uses an open source library there's no contractual agreement that the developer must slave away for free and fix stuff for the big company. The developer, or the company that develops open source, can just essentially say "fuck it!" and do whatever they want.
Instead, the big company can take what's available. If it's not enough, they can contribute to the open source project (a wise move!), find a replacement project to ride on, or buy or write their own implementation.
Not all open source developers work for free but many do because they want to spend some of their time building something they care about. If the project has big impact sometimes the developers get hired to continue working on the software on a payroll. This is probably a win-win: the developer gets paid to do what he would be doing anyway and the company gets stability into future development.
If open source developers want to build a good, trusted brand of their software then it of course takes continuous involvement to support their users and can lead to burn-outs but that has nothing to do with open source. The exact same applies to building an established brand out of proprietary software.
And that effort only makes sense in the first place if there's a chance for a significant financial payout in the end, or the developers really, really just want fame in which case they have their own priorities on how they want to resource the development.
Still, nothing to do with open source per se.
I bet a thousand-fold more developers are burning out in jobs working on proprietary software.
“Open source developers need not be burning themselves out, they can just choose to work on what they want.
” – that sounds nice, but you must be missing something, or we would not have the phenomenon of OSS developers burning out.
The observation that people in paid jobs also get burned out doesn’t give much insight into the curious, sad reality of the experience of an OSS dev working to to the point of burnout for a constant stream of non-paying clients who are often rude and unprofessional in their interactions with you.
Open source developers can’t ‘just’ choose what they work on, anyway. There are benefits in maintaining an OSS project (exposure, satisfaction at making something that a lot of people use) but these only apply if you focus your efforts on projects that become popular, which are exactly the projects that suffer the problems discussed in the article.
Open source developers can’t ‘just’ choose what they work on, anyway.
Oh yes they can.
However, if the developers choose to chase popularity, then it's a different game and they must recognise that the stakes will be higher then. Yet that has no relevance to open source itself.
You can very well chase popularity, satisfy rude customers to the world's end, and eventually burn out writing a closed-source shareware application, too.
I tried to convey they point that the fact that there are burned out open source developers is not an inherent trait of open source itself.
You don't need to open your source to get rude customers, endless demands, and gigantic requirements. If you choose to deal with all that then that is always your own choice and you must face the consequences. But it's the same class of problems whether you write open source or start a pizza restaurant. Some customers are just net-negative. In any business or hobby where you provide something you must learn to set limits to how high the customer's bang-for-buck must be for you to come meet in the middle.
I would tend to think there are more open source projects that are abandoned rather than with burned out developers, but I obviously don't have data on that.
It is... really weird. I think it might be related to how the boss will be more respectful to you after you successfully negotiate a raise.
Like normal people are somehow wired to treat more expensive people better than less expensive people. The immediate explanation is that normal people are kind of jerks?
I mean, I'll put up with more shit for a lot more money... but that's not how it works. As I've gotten paid better, every step of the way, I got treated better in other ways, too. And that expectation is built in everywhere.
> do you maintain open source projects that actually have users depending on it?
I’m asking because when people say that OSS devs of popular projects suffer from burnout, that’s not an opinion, but a matter of fact.
Not the author of the parent comment and not a maintainer of a popular open-source project, but could you explain the process of how devs get into this trap of burning out? I mean, there are quite a few projects that have been abandoned by people who lost interest or have too much on their plate, so their authors are by no means forced to stay on the project if they no longer want or are able to. These projects can be forked or taken up by other maintainers.
As the creator and maintainer of a project, it's really hard to let go of said project.
It's really hard to completely abandon a project you know people are relying on. You do feel responsible for it in the end.
Also, nearly every time someone opens a ticket, it points a deficiency in your project, and it's somewhat hard to accept that your project is not "perfect" (spoiler alert, it never is). Consequently you, as a maintainer, always want to fix issues or implement obviously missing features.
Also publicly admitting that your project is abandoned (by an header in the README for example) is quite hard, it feels like a failure and at least, you are publicly admitting something with a negative connotation.
"Maintained" forks that take over the initial project are extremely rare.
In most cases, a fork will be tiny modifications done to fit one user's specific need.
Nobody really wants to factorize these modifications into a common solution and maintain it.
Well maintained forks do happen, but only for highly projects.
I'm speaking out of experience, I maintain a bunch of projects, not highly popular ones (a few dozen stars on github), but definitely used by other people. And in these projects I've a few that I definitely have nor the motivation nor the means to really maintain well.
Typically I created a puppet samba module that is quite successful, but I've not used Puppet in 3 years, so I'm not a consumer of my own software anymore and I've not followed the evolution of Puppet in years, yet, I've not set my mind on publicly stating that this project is not maintained anymore.
Lastly if I do get PR for these projects, these are generally not really complete quite complete, documentation and unit tests are always missing, and the code quality is rarely on par, specially if the PR is quite complex. For every PR I accept I generally have a few commits to complete it/fix it.
You can easily fix the low quality PR issue with a CI setup.
Setup a Travis job to fail often (build, lint, test, coverage, etc), so you pressure them PR author to complete it. This will make the entry barrier massive, but helps you focus your attention.
In addition, take an hour setting up issue and PR templates and guidelines in GitHub. A good readme with an FAQ section helps too.
We love to code and the projects you work on become like your babies. Have you ever heard of this expression from people doing what they love, or from people starting their own companies? "Like your baby"?
Well the trap is that you end up putting a lot of work in it, at first it's for fun, but then it's because what you're doing is popular and you hope of leaving something valuable behind.
And unfortunately these things happen:
1. the project is never done, there's always some feature that people want or some bug waiting to be fixed, or some dependency waiting to be upgraded (these are the worst) and if nobody does it, then users will end up abandoning the project
2. people willing to contribute are very rare and people capable of great contributions and of sharing the maintenance burden are like unicorns
So the answer is: if you don't keep doing it, the project dies. In which case all of your effort was for nothing.
Projects have a lifespan. They don't have to be monuments for eternity, and if they get abandoned because the maintainer gets bored/burned out, it often is because the problem it was trying to solve doesn't really make sense in the current landscape anymore. The development time wasn't "wasted" if the project served its purpose in its era.
There is also part 3, someone picks up an unmaintained project, cleans it up and makes it workable. Or patches in the feature.
This is what cannot happen in most shareware or freeware apps. It depends on the source code repository being easy to find, so centralized big ones win. (SourceForge, Github, Gitlab, etc.)
The sad part is companies not delegating a person to maintain or develop critical dependencies even though they could.
> In which case all of your effort was for nothing.
I thought people maintain open-source projects if they use them themselves. In which case, all your effort was for solving particular use cases that you had.
When developers have no further use for a project (e.g. when they've moved on to a different technology), then the project will likely die. I haven't seen many people keep maintaining a project after they've stopped using it.
You can stop using the tool yourself, but still have a large active userbase depending upon it. As a result, you can still end up with an unwritten obligation to support that userbase.
You end up having unwritten obligations to your users.
You can start from the position that you can write your software, make it public, and you have no obligation to do more. Some people do just this. But once you have to (or feel that you have to) answer support questions, fix bugs, add features, make releases and do so on an ongoing basis, you can end up in a situation where you effectively have a second full-time job.
I'm not saying that this is desirable, or even necessary. But it's a reality for many open source project maintainers and contributors. You get sucked into it. End users have expectations, and it's only human to try to meet them. I've personally been very badly burned by this, and I've get to contribute at anything but a minimal level for the last six years as a result.
One of the things which I don't like are that people can have very unreasonable attitude towards what they can expect from a person who does this in their spare time who helps them for free, sacrificing their spare time for someone else's benefit. The longer I've been doing this, the more I appreciate that it's not as sustainable as we might like to believe, and that being fairly compensated for work is no bad thing. We should be more willing to say that we would be happy to fix that bug, or add that new feature, so long as we are paid for it. But in many projects this isn't politically or practically possible.
The op comment did not say that they are not getting burned out but that they need not get burned out. Instead of listening to twitter drama just do whatever you want and if people want stuff you don't feel like doing then they can do it themself
So by the analogy popular OSS maintainers have cravings to satisfy/answer/handle every last little bit of report/email/tweet about their project? Because if they have, that's no inherent to OSS, that's inherent to humans haven't evolved sufficient self-control against larger than tribe societies, and that's exactly how some humans have insufficient self-control to resist overeating. It's not their fault, but it's still their decision.
Just as a point, I’ve helped with open source projects under commercial interest. I’ve fixed bugs and created documentation and all I got was a fuck off or silence from the maintainers.
So I don’t bother any more. Most of the time I build a new wheel that benefits no one.
Fostering a good culture requires lots of work from both sides, contributor and maintainer.
I’m not saying all projects are like this but I’ve waded into too many of these so far.
This very much depends upon the project. Being open source doesn't imply an open development process. It's very frustrating when people ignore contributions.
On the other hand, some contributions can be very expensive to integrate. If they require extensive review of the design, the code and then testing, it's imposing a huge burden on the other party. Clearly, this doesn't apply to trivial bugfixes the same way it applies to feature additions and wide-ranging refactoring, but it's important not to forget the costs which have to be borne.
It's always a pleasure to contribute to a project which has thought about this, and actually dedicates resources for external code review and integration, and actively fosters a strong and loyal community around it. It encourages repeat contributions and deeper participation, and is genuinely of mutual benefit. But not all projects can afford to do this, particularly smaller ones where a single person has to forego their evening to look at your stuff.
> Open source developers need not be burning themselves out
What about responsibility to one's users, and the computing community in general? As we very recently saw with the event-stream fiasco, there are consequences when the author of a popular piece of software tries to retire from maintaining it, because of burnout or any other reason. What if they can't find a suitable successor? What do you suggest should happen then? Just freeze it, letting it break as things it depends on continue to change?
If it breaks visibly (which tends not to include security issues), and if people who didn't come forward to be maintainers of the original suddenly get motivated to be maintainers of an active fork. That's not really a very good succession plan, and the people who actually write software know that. It's why those who have some sense of responsibility and professional pride risk burnout maintaining software they'd rather be rid of, but those who lack those qualities will never understand.
Social pressure exists regardless of the source code distribution model and whether it's free or paid work.
People can always succumb to social pressure. Open source developers do suffer from that too but taking up on social pressure is not inherently relevant to the project being open source.
i m not talking about real life social pressure, but github turns software social, with all the anxieties that come with it. and people do want it to reflect well on their profile/CV. In my experience, the expectations from other people in the community is a big motivator.
> and people do want it to reflect well on their profile/CV.
Ah, there you have it. It's not related to Open Source.
The problems so oft complained about usually show up when what you really want is to be popular. Popularity takes more work, and different kind of work, than just delivering software with open source.
That's one of the funniest titles I've read in a long time.
That said, this is an incoherent rant. What does Google/Facebook's "jealously guarded" user data have to do with how FOSS developers are treated and remunerated?
I get the feeling that if I could time-travel back to magically solve the social media and data privacy problem purely with FOSS, some other non-sequitur complaint would pop off the queue into the slot for that sentence.
["Besides, even with FOSS we still don't control the hardware", "FOSS UIs stink", "Year of the Linux Desktop LOL", "FOSS has just as many bugs as proprietary software", "GNU is less secure than IOS"].push("etc.");
> That said, this is an incoherent rant. What does Google/Facebook's "jealously guarded" user data have to do with how FOSS developers are treated and remunerated?
It's because arguably in the past (80-90s) the highest value was with the code, and it was it that was jealously guarded. Now the code doesn't have that much value and there are clones of almost everything, and the weight shifted towards the piles of user data. In other words, if I'm motivated enough, I can create a Facebook clone (with less useless functionality but arguably better user experience) in 2-3 months, but I'll never be able to gather a fraction of the user data they managed to get.
You can't create a facebook clone in 2-3 months. Facebook is like FacebookOS, it probably has emacs somewhere in there. The size of functionality that FB provides is like a Mammoth (one of the ones standing on a turtle with the world on its back).
Maybe something simpler with some subset of the functionality that some subset of users care about. Your point still stands about taking a long time to suck up the data. Also, now you'll probably get thrown in jail for doing 1% of the shady evil shit FB have done (and continue to do!).
> Facebook is like FacebookOS, it probably has emacs somewhere in there. The size of functionality that FB provides is like a Mammoth (one of the ones standing on a turtle with the world on its back).
I'm aware of that. The question is: how much of this functionality is actually used and appreciated by the users?
> Maybe something simpler with some subset of the functionality that some subset of users care about.
I'd venture to say "the majority of users care about". I did some amateurish research a while ago asking people how they are using FB. Most just scroll the feed, chat via FB, click "like" and occasionally comment; some participate in FB groups. There is a ton of functions rarely used, and some are deliberately broken (for example, FB deliberately removed past birthday notifications to create a sense of urgency to log on more often, and you need a workaround to catch up if you log in less often).
If you actually start using HumHub and compare it to FB, the former is a real pleasure to use. Will it ever have more users? Practically speaking, it's impossible. In any case, my point is not how fast one can create a usable FB clone, but that the code itself is no longer something that need to be jealously guarded.
> I'll never be able to gather a fraction of the user data they managed to get
But they got that user data, though having the code. The code is still the essential bit in the first place. If someone else had had the Facebook code before they did, they could have gotten the data.
Aside: FOSS UIs may stink, but I've never really understood this. As the UI should be the easy bit. That said most web sites, browsers and even the desktop still has quite a poor interface. Remarkable given the technological options.
It's boring to do UI when the tooling is outdated and poorly documented, and when the potential audience for one's creations/improvements is miniscule.
Not that long ago I read a blog where the author had either created or leveraged an HTML5 canvas-based implementation of X11 to explain and give inline demos for how X11 works under the hood. It was a blast to read and inspect, and I bet it was fun to write and implement!
Now-- re-implement that blog in the toolkit of your choice without leveraging that toolkit's webkit widget. Then make sure to release binaries for all the common systems someone would have used to read the original blog.
You're going to have a very, very boring time doing that. But that boredom isn't inherent to doing UI as the original blogs shows. Instead it's due non-optimal tools that end up eating all your concentration, and the fact that nearly no one will be there to cheer you when you reach the finish line.
Possible exception for Qt. But even there you've got to do extra work to compile binaries to ship for each platform. Or you somehow run it in the browser which is experimental and not nearly as well-documented as just using existing web frameworks.
That's your problem right there. Many (most?) FOSS contributors are in it for the intellectual challenge. Designing a good UI is perceived as a lesser problem compared to technical challenges, and therefore disregarded.
Also, design is not the comfort zone of most FOSS contributors (which is why some FOSS projects do dedicated outreach programs not only to women or minorities, but also to designers).
Also, I think there is still some "it was hard to write, so it should be hard to use" mentality. I frequently see it justified it as an avoidance tactic for developer burnout: By making it hard to use your software (e.g. by providing no documentation, or by coating the documentation with a thick layer of jargon), the only users you'll get are the ones persistent enough to work through that on their own, and those will be the ones that deliver high-quality bug reports and contributions.
But there are many rewards to wrapping these products up. MS did well with their little tabbed UIs and checkboxes. It felt more like a mixing desk, easier than say discovering and typing command line options.
I don't think people have a 'this should be hard to use mentality'. I've been with programmers and designers who have had not one idea about designing the interface. They are fine cloning, but not at innovating. And frequently the UI is just born out of cluelessness. Or with websites, the design constraints sometimes override the ergonomics, or even kill code orthognalness.
These are common explanations to read online, but when you Occam's razor them to another explanation (which I'll share in a second) they build unnecessary narrative around motivation.
What if lots of open source GUIs are bad for the same reason many commercial and enterprise-internal GUIs are bad: the core of the problem was solved and the team lacked sufficient incentive to keep working on quality of life enhancements.
Funny but, at least in the USA, public toilets are a great example of the tragedy of the commons. They are almost universally destroyed. In malls and shopping centers, in fast food restaurants and cafes, in movie theaters.
I'm sure there are worse countries but I also know there are plenty of better countries. As an American it depresses me. My culture seems to be one of "it's a rite of passage to destroy the commons" that includes kicking in the doors to toilet stalls until they break. Peeing standing up in a toilet when their are perfectly good urinals. Putting entire roles of toilet paper in the toilet "just for fun". It's so common that AFAIK it's just assumed that's the way the world is. It's not. Plenty of other countries don't have that culture.
I've often wished someone one like The Lonely Island would find a comedy meme to make it embarrassing to be caught trashing/breaking/abusing public restrooms. Well I can dream that my culture would change.
I have literally never seen a public toilet in this state in Australia. Is this common across all of the US? The public toilets here are at worst dirty because of a lack of cleaning but not a malicious effort to ruin them but often the public use but private owned toilets in shopping centres are next to perfect.
Interested to know how unique US is in this regard. If your name checks out, I assume Japan is one such country where things differ from your experience. I would guess that Japan is the exception though, not the rule.
Why do you assume the behaviour in the US would be the rule? I have on occasion come across toilets in a terrible state, but for the most part, toilets in Europe, paid or not, tend to be fairly decent. In need of cleaning, sure, but it's certainly not common for people to kick in the doors or anything like that.
Well, the office in which I'm currently working seems to have some people with a surprisingly poor aim, so there's that. But there's certainly no culture to intentionally destroy the place.
I wouldn't say it's common for people to kick doors in either, I'm sure it happens though. More likely to happen at a place like a dive bar - that wouldn't surprise me, or some place where the bathroom appearance isn't seen as a high priority - like a gas station.
I haven't lived anywhere else only traveled so my experience elsewhere is only from a few days. Found toilets nicer than anything in Japan in Copenhagen, Stockholm, a few places in Germany. They usually had a fee of 10 to 50 cents and so stuck out in my memory but like I said, only there a few days each no idea what the norm is.
But if the clean toilets have controlled access that requires a fee for use then that mitigates tragedy of commons effect. Not aware of many places like that in the US.
FOSS like a free toilet needs maintenance from time to time. In Thailand, the toilets are pay in some areas and they clean them and take care of them. In the USA they used to have paid toilets but got rid of them because it was called discrimination against the poor.
A reason why pay software does so well is that there is hand holding within a phone call away if something goes wrong. With FOSS you might have a bug report and hope it gets fixed in the next release.
On the other hand, I'm having a hard time thinking of a single pay toilet in Japan where I live. I'm sure they exist, but they aren't common. The toilets are also spotless, by and large. It's part of the business ethos to provide clean toilets for the public.
The idea that businesses should pay for software that is important to their infrastructure is somewhat similar. I mean, you don't have to pay, but businesses are increasingly getting the idea that it is good for their business to do so. Although I'm a dyed in the wool "Free as in Freedom" guy, I think the Open Source movement has done a lot of good by explaining to businesses that it's not just an ethical movement. It's good for business too. That message is important.
> A reason why pay software does so well is that there is hand holding within a phone call away if something goes wrong. With FOSS you might have a bug report and hope it gets fixed in the next release.
I dont want to play any kind of fanboy here, but in case of many software products unless you talking of huge corporate customer it's very unlikely to get any kind of proper fix faster than in open source software. Yeah there is few software companies that play close attention to end-users problems and rapidly provide fixes, but in most cases you have to wait month+ to see fix included in some future release.
What author in the link is talking about is that end users of FOSS aren't often financially support developers or just random people who play role of user support within community.
Perhaps not a sex offense, but it can still be illegal. Here in the Netherlands it's illegal in the "bebouwde kom" (basically within a village/town/city). But it's fine when you're in a forest somewhere (within reason - don't piss on someones leg).
In Europe you have to try very hard to fall below the level where you can afford 1€ for a toilet. Arguments that poor people can't use pay toilets don't really work with all that money spent to make sure people always have enough to life with some dignity.
...it's not about affording: when they're drunk and can't find any change in your pocket, they end up pissing on a wall and stiking up the whole street. Some things need to be free even if they are easily affordable simply because (1) there's enough tax money to cover for it, and (2) a (large) proportion of people will simply find payment inconvenient so won't use the paid service, making life stinkier for everyone around.
But hey, at least they got it right with EDUCATION, which probably matters more than this :)
The author decries that governance and tragedies of the commons are for inert resources. This is not the case, but perhaps this thinking pervades software projects. We can learn from Elinor Ostrom's economics work, as well as from Christopher Allen's thinking/writing about the commons of open source projects in particular.
Ostrom’s Design Principles for Collective Governance of the Commons
I get the author's point, and it's a good one, but I think it could be better made without connecting free software to defecation. The metaphor I'd reach for might be more like a park bench or water fountain, which can also be appropriated or degraded by selfish users but doesn't start out with that negative association.
You mean you want companies to stop relying on FOSS and start paying for people to write "better code" for them while at the same time programmers should stop working on FOSS and just start working on things they're paid for? Great idea, that will surely improve things.
By the way whatever happened to attempts to set up FOSS licenses that prohibit the usage of "free" software on a range of damaging exploitative activities? Eg. "It's free, or one million per day if your company pays any worker less than a living wage / kills people / allows enforcement of human rights violation like, ironically, restrictions on freedom of speech..."
> Low-paying organizations do poorly in competition with high-paying ones, but they do not have to do badly if the high-paying ones are banned.
> All sorts of development can be funded with a Software Tax:
> Suppose everyone who buys a computer has to pay x percent of the price as a software tax. The government gives this to an agency like the NSF to spend on software development.
Given that much of the Free / Open Source software is for the public good, critical FOSS could be funded via taxes, I don't see why not.
Of course you can be anti-taxes and prefer a minimal government, you can be an anarchist like the folks in this community tend to be, but we do pay taxes, for roads, for public schools, for public healthcare and as long as we are paying taxes, I don't see why some FOSS couldn't be funded by the state.
> As an engineer, I shall participate in none but honest enterprises. When needed, my skill and knowledge shall be given without reservation for the public good.
I've taken a similar oath, but I don't think it really addresses polotics's concerns. Each of his mentioned topics are subjects which you could discuss and debate at length because reasonable people could disagree, especially when considering specific cases.
The Obligation is not specific enough to deal with complex problems which may have multiple different points of view. The point of it is for you to think about the morality of your actions and to do what you think is right. But, polotics would presumably like to require you to do what he thinks is right.
The problem is that nobody really knows what "Do No Harm" really means, so it's effectively useless to include this in your license unless your goal is to get nobody to use it.
There are some clear examples mentioned in the DNH license text. Also, if a project or company discovers their purpose or business model has adverse effects for a significant population or evosystem, that would signify harm. The "ethical source" licenses are encouraging software developers to be proactive in our duty of care for the general public.
That list is not useful, for two reasons: one, the quality of the list isn’t great, because it’s by no means exhaustive, is subject to the ethical whims of the maintainer, and is too general (e.g. “violence (except when required to protect public safety)”-what is this supposed to mean? Can’t every government say they only perpetuate violence to protect public safety?) The other part is that you also need to prove that I have been doing the action, which hard: if my company sells computers and some of them end up going to the NRC so they can send email, is the company suddenly in violation of the license?
I understand that ethical definitions are fuzzy. Just because we find confusing or unresolved ethical areas, does not invalidate efforts to clarify an ethical standpoint.
The list can never be complete, nor should it be exhaustive, but it is a living document (PRs are welcome). An ETHICS text is intended a candle in an otherwise darkened space. It is intended to promote critical thought about these pressing issues, and to take action to improve ourselves, our projects, companies, and communities.
They don’t count as ‘Open Source’ according to the definition of the Open Source Foundation: https://opensource.org/docs/osd
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
Sure, you can make such software, but who would take the risk to use it in a corporate environment? Without traction you're not going to do much good anyway.
Edit: Why the downvotes? It was a serious comment:
"establish a form of cooperative which would function in the same way as the copyright collection societies [...] Members would assign their copyrights to the cooperative, which would issue free non-exclusive licenses to other members. [...] Non-members could still use the works but would have to negotiate and pay a licensing fee in the normal manner. The original twist is in the criteria for membership of the cooperative, which would be limited to those who do not employ wage-labour or capital-intensive technology in producing cultural works;"[0]
The EU has a lot of software projects and a lot of them are open source (EUPL licensed, which is compatible with most other FOSS licenses, it's sort of a EU-compatible GPL). The problem is that most of it is self-dogfooding software, ie, software that meets the needs of the EU governance, which is not necessarily something that is a need in a lot of other institutions like corporations.
You're, however, free to release software under EUPL to indicate you support the EU in the free software effort.
Software often doesn't look like a good idea up-front, so nobody would pay for it up-front.
If you went to the government or a charity in 2003 before Facebook and said you wanted funding to build it because it'll be critical to society in the future, you'd be laughed out.
And there's no guarantee that what you would build wouldn't be horrible in the same way because it might be inherent to social media (vs inherent to ad-driven social media... I don't know but no one has the data), or possibly horrible in a completely different be way from how Facebook is horrible now.
That's a good question. On the one hand, probably there would be much being developed which isn't used (like the search engines subsidized by the EU). On the other hand I'd love to see a real OS/Desktop alternative being developed. I use Linux now, but I think to be used in Enterprises or public service it lacks features as good central maintainability (where Microsoft really shines). AD integration is really difficult with Linux Desktops and I am not aware of any (good) alternative to group policies.
I absolutely loathe the fact that Windows (and Windows 10 specially) is used in public services.
"""I use Linux now, but I think to be used in Enterprises or public service it lacks features as good central maintainability (where Microsoft really shines)"""
I think in a Linux only environment maintainability is pretty good. Especially for centralized software rollouts and updates (and security fixes) I prefer Linux over Windows. There's virtualization and software packaging solutions in Windows land but from my experience the things that work best are usually from third parties, cost quite a bit and don't work all that great in many edge cases.
For user management in Linuxland, Kerberos for authentication and LDAP for authorization works pretty well. But AD in Windowsland is very good.
As you said, the problems start once you enter a mixed environment (which is pretty much always the case). I'm not sure if the blame should be put on Windowsland or Linuxland in mixed environments but it's usually put on Linux.
Any good literature how a proper Linux only landscape is maintained?
Previously I had an AD domain running (to integrate Win7 machines) via Samba4. When I switched the Win7 machines to Linux, I found usage awkward (performance, strange user names such as name@domain.local, slow shares). I switched to local users and sshfs instead of shares. This would make for a more convoluted onboarding of new users (which is not a use case for me). However I'd be interested how this would be solved in an Enterprise environment.
If central government develops something then I would expect it's going to be specific to their requirements. Local government on the other hand could get huge benefits from sharing code.
The analogy is flawed. There is no congestion and wear associated with software library use.
Also I am not afraid of FOSS dying or shrivelling up. From the perspective of a career software developer or manager it would be a new golden age of in-house development and library sales.
No. Less open source software does NOT mean more jobs. It means fewer. For example, if every startup that ever started had to buy a commercial database @$100K license before doing anything, then very few startups would have evolved. And all the employment they eventually generate would not materialise. Free software was a huge factor in making the Internet possible and all the jobs it created.
Shoestring startups would use a $10 shareware database, which is still a proprietary commercial database. Or they would use the stripped-down, free/cheap version of the $100k database. Or they would pirate it and scramble to make $100k before they get caught.
Congestion and wear in the form of outdated dependencies, security vulnerabilities, technical debt, and ever-changing platform/os compatibility requirements. Surely these things fit the analogy?
I think you are probably right, there are a handful of companies that benefit from open source but as individuals I suspect we all loose a little by devaluing our creations.
If a big company uses an open source library there's no contractual agreement that the developer must slave away for free and fix stuff for the big company. The developer, or the company that develops open source, can just essentially say "fuck it!" and do whatever they want.
Instead, the big company can take what's available. If it's not enough, they can contribute to the open source project (a wise move!), find a replacement project to ride on, or buy or write their own implementation.
Not all open source developers work for free but many do because they want to spend some of their time building something they care about. If the project has big impact sometimes the developers get hired to continue working on the software on a payroll. This is probably a win-win: the developer gets paid to do what he would be doing anyway and the company gets stability into future development.
If open source developers want to build a good, trusted brand of their software then it of course takes continuous involvement to support their users and can lead to burn-outs but that has nothing to do with open source. The exact same applies to building an established brand out of proprietary software.
And that effort only makes sense in the first place if there's a chance for a significant financial payout in the end, or the developers really, really just want fame in which case they have their own priorities on how they want to resource the development.
Still, nothing to do with open source per se.
I bet a thousand-fold more developers are burning out in jobs working on proprietary software.