Debian project has plenty of money but not enough developers
theregister.com
theregister.com
It would be neat if they could split the difference between free and real job, but I wonder if part of the reason they don't is that they want people who care unreservedly about values and code quality rather than people who need $500 a week?
Clearly working full time on Debian is of value to society, a good use of time and clearly verifiable by committed contributions.
Definitely worth the living wage.
I have a rather strong emotional reaction to this because to me a major reason for FOSS is to break the problem of perverse incentives that arise in corporate -and- government work. Governments want to control their populace. The NSA, for example, has made algorithm suggestions that would give them an easier time listening in on the world. And the US has prominent figures arguing for encryption backdoors that supposedly only the "good guys" would have the keys to. Which is to say nothing of governments that outright ban encryption. So I would be very skeptical of FOSS officially maintained by a government (though I suppose its open source nature would still be a point in its favor for the transparency).
I thinks it's two different problems: maintenance and cleptocracy. For example, should the government maintain roads and bridges? It falls within the common good (public infrastructure) so using taxes for that makes sense.
But, if the government has authority over the bridges, how to stop them from performing obligatory cavity searches (or some other bad thing) on people who use them? That's not a question of what the responsibilities or objectives of a government should be. The question is how to reform a hostile, cleptocratic government.
I won't presume what context you're coming from, but I've noticed that in some cultures it's normal to think of the government as "them". For me it's "us". While someone from the former group might say "government does that", I'm inclined to say "we do that". My outlook seems to be more common in Europe than in US, I think.
For me, using the government is the most direct and efficient way of maintaining FOSS, or doing anything that should be done by "us", as opposed to by "somebody". I see that as the purpose of governments.
These FOSS projects spanning many borders makes things slightly harder, but that's just because we're not used to that kind of cooperation. In principle there's no reason multinational programmes for financing these things can't exist.
Alternatively, make it difficult for states to use non-FOSS software. That way you'd redirect all that money being wasted on closed source.
Sponsoring large research projects might go along way though.
> Governments want to control their populace.
That's a pretty broad statement :)
In my country we have free speech, and the state/government protects freedom of speech.
Similarly, my government tend to promote human rights. I think that can still be said about the US too.
No governments aren't perfect, but control is not their major concern.
There's no government layer at the level Debian operates. As pretty much everything internet based, its users ( and contributors) are international - which I think is the main reason why we don't see public alternative services to social networks, search engines, etc.
China is a special case, since they explicitly would rather keep the userbase restricted to Chinese citizens.
There are tons of federal agencies that could sponsor FOSS.
https://www.usa.gov/federal-agencies/
I'd love to see a program where FOSS devs could get say 2k-4k tax free per month depending on part or full time work. A billion a year would pay for just under 21k developer years or close to 42k part time devs.
Federal, state and local governments burn some large integer multiple of that amount every year on proprietary, closed source software.
probably not an integer, more likely an irrational number
But, perhaps you were joking and it's an 'irrational' amount?
I'm afraid of this part gaining significance over other and its side-effects becoming main effects.
Job Guarantee isn't as good of an idea as you'd expect: https://slatestarcodex.com/2018/05/16/basic-income-not-basic...
There is no magic porridge pot. Somebody has to make the stuff you want to buy, and they ain't going to waste their life making stuff for you if you're not doing anything in return. Why should they?
Personally I'd love to be making more open source contributions as well, and I've been thinking off and on about taking a sabbatical to make time for it, though that probably won't happen.
I might be able to help find dev work for you that doesn't involve technical interviews, though it may not necessarily be a "job".
The person who made me the offer was very apologetic - as she said, it's not even my day rate - but as I said, I'd probably do it for nothing, no one's making a penny out of the software, it's really useful, and $500 isn't nothing.
I think they could get plenty of people to work on Debian for 10 hours a week for $10k a year, as a hobby.
I'd happily code all day long on stuff I really care about for minimum wage. And when I day minimum, I don't mean the penance described by the law that forces you to have multiple minimum wage jobs to get by. No, I mean one single job that pays enough to get by.
Even if that becomes the case, since this stuff goes though phases, a lot of college students or kids right out of high school would still jump at the chance to gain this sort of experience, alongside people like you, who just want their needs taken care of, a bit of spending money, and a job where they can focus on what they enjoy without too much demanding or stress. Same for older people with a lot of expertise, but who again want something less demanding but still enough to support them until they retire, or give them a purpose after they do so.
Like my dad, he's a network engineer, in a job like I described. He and my mom are a little over retirement age and plan to retire soon, but he's not one to just sit around the house all day. I think that's one reason he keeps saying he'll retire in 2 - 3 years, but says that year after year.
No, I'm thinking if you pay peanuts you'll get monkeys. It is rare for a situation to stay the same after money gets involved. People make decisions based on money.
Maybe it's because I'm not big into the development side of things, but I cannot recall any programs that'd be similar to bug bounties but focus on someone building code or fixing the bugs and submitting that in a freelance type capacity.
Granted, my limited knowledge of development may just mean I don't see obvious reasons it's not done or widely known about, and there would be a few different things thatd need to happen vs how bug hunting works, but its similar to your idea to attract more talent to work on small bits, without going out and hiring full time developers.
A volunteer gets to choose what he wants to work on and if he wants to work at all. An employee/contractor does what his boss/customer wants him to do and get compensated (i.e. paid) for it.
There are many reasons why you may want to pay someone. The obvious one is to do things no one wants to do for free.
But maybe you also want a proper contract, to make sure some essential job is done fully. Volunteers who work on they spare time will stop working for you once they stop having spare time, and there is not much you can do about it, both legally and ethically.
Sometimes you also need certifications. I don't know how it applies to Debian but certified people usually don't work for free. The certification process can be expensive and they can have legal responsibilities. Even if people can offer their time and skills for free, legal responsibilities are usually off limits.
As an example, I volunteered to staff a few events. None of the regular staff and organizers were paid. However, security was paid. While we had a few burly guys, no one wanted to take responsibility, and probably couldn't anyways.
But that makes no sense. In reality, there has to be some sort of decision mechanism over what packages are included and what aren't. If that decision isn't made pro-actively, it will be forced upon you - via the man power problem. Debian is at its heart a do-ocracy, which boils down to something happens only if some individual can raise the energy to make it happen. So a package dies when no Debian member can make (unpaid) time to save it. It's not like there is someone who can order someone else to save it - Debian is a purely volunteer organisation.
It's easy to paint that as having a man power problem, but curating the packages is essential task that must be undertaken. Doing it isn't "a problem", it's essential to survival.
It's also easy to criticise the way this decision is made. Just leaving it to the individual decision making of 1k volunteers sounds so unorganised. But the flip side is if you have paid engineers you are doing the reverse, you are giving someone the power to order other developers around. In an organisation like Debian that attracts membership through it strong egalitarian principles, that's going to be an anathema to most of it's members.
As an side, despite all the whinging here while it's difficult to introduce a new package to Debian, it is not difficult to step up to support an existing package. You don't have to be a developer or a maintainer, and there are any number of existing developers and maintainers who will upload your work if you do it. So if a package dies, it's not too far from a stretch to say it was because no-one on the planet with the skills was that interested in doing the work.
https://lists.debian.org/debian-project/2006/10/msg00260.htm...
That doesn't mean that it cannot be done. E.g. the FreeBSD Foundation pays developers for specific projects that are important to the future of FreeBSD:
There were valid reasons for the hostility. Bringing money into the equation completely changes the dynamics of an all-volunteer project, and splits the developers into the gilded minority and the plebs who slave away for free. Plenty of volunteer organisations have been torn apart by the resentment and infighting that can result.
* Which developers are eligible for funding, and which are not?
* The organisation is no longer flat; some people are effectively profiting off the backs of the majority
* The meritocracy is lost; do the "paid staff" have more of a say than the "unpaid volunteers"
* Are "paid staff" even volunteers any more?
The vast majority of Debian developers work full time on their day jobs, and contribute to Debian as a labour of love in their spare time, or as part of their work for situations where organisations sanction Debian work.
I used to work 8 hours, and then come home and regularly work 4-8 hours on Debian. Every day for nearly a decade. Totally unsustainable, and I'm no longer an active contributor. But for people who are contributing that much, for free, you can see why there would be concerns over the effect of a paid class of contributor to the organisation as a whole.
None of that is to say it can't work. FreeBSD is smaller, more tightly-focused, and has a culture of corporate contribution. Paying people to write specific features delivers results on a schedule. I donate to the FreeBSD foundation for that reason. The developer culture seems to be much more tolerant of this (though I'm not a FreeBSD insider, so don't know all the details).
FreeBSD is vastly simpler to contribute to, so I can participate with vastly less commitment. Contributing a new port or an updated port or bugfix is simply a matter of attaching a patch to a bugzilla ticket. Maybe it's not so much of an issue because there's already a clear separation of core devs vs casual contributors. And that's OK.
Is it a meritocracy if only developers who can afford to work for free participates?
Debian is an all-volunteer organisation. Those are the terms for participation and they apply equally to all. If you want to be paid for writing free software, then get a job with a company that does that. Debian is not a company.
So people who are wealthy enough to not have to worry about getting paid for their work have more merit than those who need to make rent?
This seems like a very Jane Austin-era view of meritocracy.
Debian contributors are volunteers. They volunteer their time, personal resources such as compute hardware, bandwidth etc. Some pay out of their pocket for running mirrors, compute resources and other infrastructure. Other parts are paid for by donations and infrastructure provision by sponsors. But far from all of it.
So at a personal level, individuals must be able to support themselves sufficiently to be able to contribute. That's no different from working in any other volunteer organisation which requires a commitment of free time and other resources to participate. That's life. Nothing comes totally for free. The bottom line is that participation at a minimum requires you to donate some of your free time. You're a volunteer, not an employee. What more do you really expect here?
In other words, I think this reply shifts the context from "will paying volunteers harm the project?" to "is paying volunteers morally right because it enables wider participation?"
Overall, I can see it working for some organisations. But I don't see Debian as one of them.
https://ccs.getmonero.org/ (new system) https://forum.getmonero.org/22/completed-tasks (old system)
Just curious
Work you contract out is effectively saying: none of you volunteers are up to the task. We'll have to get someone better than you to do it. That's not great for the psyche of the project.
And this has already happened from a certain perspective. (I'm biased here, for the record.) Look at the systemd debate and fallout. At its core, this was effectively contracting out the maintenance of the whole base system to a third party organisation, and telling the Debian developers that they weren't allowed to touch it in all but the most superficial way. This isn't about the technical merits of the decision, by the way. It's about how the organisation went from being an independent technical leader with development driven by its own people, who were highly regarded in their own right, to being a follower being told what to do by others. It took away the primary driver of Debian's independent existence and the agency of its developers to drive change at that level. (It was a minor contributing factor behind my leaving the project.)
And like bounties, there are concerns over who gets the money. Is it subject to favouritism, influence, or other factors.
As I said in the original post, I think it could (and does) work for other organisations. What makes Debian unique is that its origins were a 100% volunteer-driven self-sufficient effort, and that essentially defines the project's culture to this day. Every bit of internal infrastructure and tooling was originally self-developed. I used to maintain some of it myself. Other organisations would have no political issues with paying a contractor to "get x done". But being a volunteer effort, actually "doing x" is as important to the volunteers as the end goal.
Many people of that type work at universities for comparable compensations. E.g. 50% E13 position at TU Berlin gives you monthly 2k pre tax. If you spend lots of your time to improve the public good, you'll still need something to put food on your table (unless you are financially independent of course, but many people aren't).
But.... sadly this is not going to fill the coffers of politicians and consultants alike, so things like these will just be daydreaming until a majority of people is fed up with corruption and not braindamaged enough to believe extremist bullshit.
I really like Debian but volunteers are probably better off packaging for other distros such as Arch or Alpine with simpler packaging/better tooling and less strict rules. One thing to improve would be tooling to make packages.
Debian's expenses are hosting, conferences and travel reimbursement -- and not a lot of that.
It's still not really a lot of money, though. As a thought experiment, if Google decided to donate $1 per installed Debian or derivative OS, I think that might double Debian's bank account.
That's a plausible funding slogan -- "A Dollar for Debian".
Do you know if any of the students who particpate in Debian's summer of code end up being regular contributors after the sponsorship period ends?
In particular I know that for years now former GSoC interns are mentoring current GSoC interns on the project to package parts of the Android SDK for Debian. This year it is last year's intern and also two others from prior years.
https://wiki.debian.org/SummerOfCode2020/ApprovedProjects/An...
I'm sure there are many valid criticisms of Debian, the main one for me is overpatching upstream packages.
Distros and packaging have much lower relevance as operating systems are viewed as applications, rarely are unix systems multiuser, often serving a single software package. Even desktop operating systems are getting containerized, Qubes, etc.
[1] Which is not to say that messaging is bad - a web interface with a proper message queue behind it would be fine. In fact that's how Fedora's systems work. It's that email is not a reasonable messaging system for this purpose.
It was pretty neat in 1998. Today, it's long eclipsed by pretty much everything else.
If I were Debian, I'd migrate the whole lot over to GitLab issues seeing as they have the infrastructure for it set up (salsa). The problem is there is a very vocal minority who still think it's not only good, but the best choice for Debian. I doubt the silent majority who suffer it agree. Like anything, it's an entrenched part of Debian culture that's hard to change. But it was time to retire it over a decade back.
This was in stark contrast to e.g. contributing to nixpkgs. Do a PR on GitHub. The package gets built automatically by CI. Get feedback. Make changes to address the feedback. And it gets merged. Of course, PRs sometimes go stale (most projects are dealing with a lack of manpower), but the process is generally fast.
But the outcomes are radically different: I never attempted to contribute to Debian again, but I have become an active contributor to nixpkgs.
I think to attract developers the process needs to be modernized. Put all the package definitions in a Gitlab monorepo. Build each PR in a sandbox on CI. Describe the submission process on a single page.
If you were to design the .deb packaging workflow today, you'd do it very differently. You would probably have a single, or much smaller, set of source repositories, and you would have a single tool to do all the core packaging work.
You only have to look at the BSD Ports, MacPorts, Homebrew, vcpkg, and other software collections to appreciate how extremely complex the Debian approach is, and how the other systems benefit from a strictly standard set of functions to do their job, making all packages uniform and easy to work on.
On the other hand, because of these considerations, Debian has vastly better support for complex versioned dependencies, and the SAT solver in apt is best in its class. The other systems manage the collection as a whole and don't need to care to the same extent.
So I would agree some modernisation wouldn't go amiss. But it's difficult to accomplish that when you have a 25 year legacy of doing it a completely different way. And you have over 20000 packages to fix.
There is a saying in German that goes
> Wer nicht mit der Zeit geht, geht mit der Zeit.
Now Debian has lot inertia and Ubuntu is a huge factor too, so there are enough incentives for people to put up with that process.
Also, maybe this is by design. By keeping the bar for every high, maintainers are not bothered by low effort PRs.
Still a happy Debian user after all these years, but I'm past the time where I'd spend effort to even try to join.
I think my first simple debian package was working within a few hours, and I was tackling more complex stuff within a few days. Not bad for a system that can handle the oddball installation requirements of just about any software, while also accounting for many install/configure/upgrade/downgrade/reinstall/remove edge cases.
I'll grant that it is a complicated system, and there's a lot of legacy stuff beneath the higher-level tools. I suppose my point is that the vast majority of the complexity turns out to be avoidable in most cases, and getting started is not as hard as it looks.
[1] https://www.debian.org/doc/debian-policy/upgrading-checklist...
Maybe also https://wiki.debian.org/how-can-i-help
Until very recently they were expecting GPG keys signed by 2 Debian developers, and that could be only done by being developers face to face, or by attending a key signing party on DebConf. Tough luck if you're in a remote location. Not sure how it's being done after pandemic.
On the other hand Mozilla has to pay for infrastructure (and here they have to support multiplatforms and multi OS developments), development, legal, taxes, marketing etc... etc.. It's not even comparable in any order of magnitude the costs involved.
If Mozilla would be to survive with volunteers would be even more miles ahead of other browsers. You can see Thunderbird as an example that Mozilla stopped maintaining since years the development pace slowed considerably.
On a side note: I really wish for the sake of the internet that Mozilla gets their s* together and start to improve their products to be really competitors to Chrome and Safari.
Generate a HTML doc with tables with 200.000 rows and columns with table cells with non-zero height/width and try to scroll fluidly on a tablet for example. Works in FF, works in Safari, doesn't work in Chrome.
True that there is historical baggage with HTML tables and maybe these optimizations aren't a good focus, but I doubt there are many website where all modern browser are at least competitive.
The performance-critical parts of vim are written in C. You can't say that about emacs. Or firefox.
The irony is that the people being hired are mostly already there doing work for free.
There is no way debian (or NetBSD) could pay market rate to compete for the time of anyone working on the project for very long so it's usually a motivational push or justification for sabbatical or "I have three months between contracts".
It's much much easier to buy hardware and things for developers who ask for it.
I suppose these projects are seeking developers with passion, personal wealth, and free time.
And yes $900K should be used to improve the situation, there might be some great developers actually need the money, or the money can get more young developer to start in debian.
Part of the issue though I suspect may be the way packages work. I am just guessing but it may be the case that these volunteers are creating packages for lots of third party software and constantly fighting with incompatibility to upgrade them. Which seems like the third parties should be more involved with updating the packages.
But personally I think that even though snaps are so hated, the relative impossibility of keeping all packages up to date and similar issues is making things like Snaps or Flatpak make more and more sense as a general direction.
I don't know if Flatpak has a way to do compression or reuse layers like Docker but I wonder if it might eventually make sense to go in that direction.
Or another crazy idea: maybe it's possible to train an AI to resolve dependency or build issues and create packages. Maybe pretty far-fetched but when there are so many tens of thousands of packages I feel like you should start going for radical ideas.
Debian has $900k in the bank. IBM purchased RedHat for $34B. The number's aren't directly comparable, but methinks a factor of 100 understates it.
It is complicated.
"The site gives me 403 Forbidden errors if I disable referers"
yah cool faq, many questions answered.
I didn't chose this architecture. But I was tasked to package it so that people could just "apt get install stuff" and start using it.
It was HARD.
The tech is very old school, it doesn't give a lot of feedback, it's hard to debug, documentation is sparse and examples in the wild are not up to date, not to mention the state of tooling. And you do all that with shell scripting, the worst language for the job. Sure you can use anything else, if you like zero doc and example.
Then we had to distribute it.
Well, turns out creating an APT repo is not so easy, either.
Now, we did all that by cutting a lot of corners, zero red tape, and only us to please. Also, the consequences of not using best practices, or worst, breaking something, were few.
On a team of 6, only 2 were really understanding what was going on. The rest were lost, awaiting instructions from us because they just couldn't picture were their work would fit in this blob of bash workflow. Now that I'm gone, I have no idea how the team is going to maintain the thing.
I can't imagine doing the same thing with the level of road block working for something as sensitive as the official debian repo would bring.
If debian wants more contributors, they have to make this stuff way, way more accessible. And be friendlier with people telling them it's hard.
Every time I raised the topic, somebody came along to say I shouldn't be doing x or y. Or just that I shouldn't be packaging something and just publish it on the debian repo, letting the debian maintainers do the packaging. It's not going to bring me to work with the community if the first taste of it is the demonstration they completely ignore their shortcomings.
And I say that while I've been typing apt commands for a decade now. I'm also french. Debian is, with VLC, Libre Office and Firefox, one of the 4 pillars of FOSS for me.
A lot of Docker is a response to how difficult it is to build packages and how invasive package installation is to the base system (Nix gets this right).
If in the future you need to build packages again, I'd take a look at fpm.
The goal of fpm is to make it easy and quick to build packages such as rpms, debs, OSX packages, etc.
Badump-ching! I'm here all week, folks. Don't forget to tip your waitresses...
Why would any hobbyist wanna use Linux?
Naaah not really, but hey tastes are different.