FOSS is free as in toilet(unhandledexpression.com) |
FOSS is free as in toilet(unhandledexpression.com) |
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.
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.
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.
As a personal curiosity, 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.
And no, it’s not the same as a regular job. It’s more like starting your own company, except without the payoff.
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.
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.
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.
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?
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.
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.");
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.
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.
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.
Edit: Spelling
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.
This is obviously untrue unless you have a support contract in hand, which means you're a business.
Meanwhile, in "socialist" Europe, paid toilets are the norm. Then again, wild urination isn't a sex offense either.
Ostrom’s Design Principles for Collective Governance of the Commons
http://www.lifewithalacrity.com/2015/11/a-revised-ostroms-de...
I mean this in the euro-socialist model. If that's anathema to you, substitute charity or benevolent technocrat.
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.
Less open source software = more jobs
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.
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!).
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.
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.
In my experience they're generally much better maintained than US toilets.
And pervasiveness of toilets is a regional thing in the US. In the bay area though, they're extremely rare and universally destroyed.
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.
My experience is mostly western Europe.
The freedom to use the software for any purpose is imo the most important freedom of all.
Straight from the horse's mouth, here's Richard Stallman on "why programs must not limit the freedom to run them":
https://www.gnu.org/philosophy/programs-must-not-limit-freed...
> 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.
https://www.gnu.org/gnu/manifesto.en.html
not personally a fan of that solution
https://github.com/raisely/NoHarm
https://hackernoon.com/6-myths-about-ethical-open-source-lic...
Software developers can also commit to a form of the Hippocratic Oath:
> 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.
https://en.m.wikipedia.org/wiki/Engineer's_Ring#The_Obligati...
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.
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]
[0]https://knowfuture.wordpress.com/2007/11/22/copyfarleft-an-a...
You're, however, free to release software under EUPL to indicate you support the EU in the free software effort.
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.
I absolutely loathe the fact that Windows (and Windows 10 specially) is used in public services.
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.
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.
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.
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.
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.
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.
Also, imagine every software developer taking an oath with the phrase you just quoted. Adtech industry would disappear overnight.
That or the promise of doing good, would just be empty signaling.
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.
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.
An accountable foundation from a list would work much better.
In my experience the less you charge the more of that stuff you get. There is something about the very bottom of the pricing scale that is toxic.
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.
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.
And there is your problem. Maybe the social functions of github are not helping?
But hey, at least they got it right with EDUCATION, which probably matters more than this :)
It's like telling fat people that they don't need to be fat and they should just eat less what's the problem.
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.
My analogy was perfect because those that preach know nothing about the cause.
No, it's not about cravings. Or self-control.
It's a good clean data set to train ML models that is the current proprietary advantage set.
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.
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.
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.
See Symfony/Symfony for a good example.
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.
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.
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 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.