This is a good, levelheaded response. But it makes it seem as if the process of becoming a sponsored maintainer was straightforward.
It's not.
A number of months ago, I tried getting trimage (a gui image optimizer, http://trimage.org) into debian. Since I already had a working Ubuntu PPA, I figured it wouldn't be too hard. Packaging instructions for debian are available at various official websites, but contradictionary and they all seem to presume you have packaged for Debian before. Jargon like RFP (request for packaging) and ITP (intent to package) is thrown around frequently without explanation.
Luckily, there is debian-mentors, meant to help upstream developers with becoming a sponsored maintainer. Most of the debian-mentors site links to outdated packaging instructions, using which will mean you will be ridiculed on the way-too-hostile mailinglist. Trying to do 'the right thing' is almost impossible, as most of the feedback will depend on the personal opinion of the person responding. I suspect this is because they, too, don't know which packaging instructions to use or point to.
Trying to get my application into debian has been nothing but a massive, timesinking frustration, and I wish that wasn't the case.
A "good" response? It was very polite and informative, and I do appreciate that - but "you can package it yourself" is still ridiculous. Imagine upstream authors needing to get packaging rights from Debian, Ubuntu, Fedora, Red Hat, Gentoo and FreeBSD just to give most (most!) users a nice way to install a non-broken version of their software.
To be fair, both Gentoo Portage and FreeBSD Ports pride themselves on shipping the upstream's software verbatim wherever possible (though on Gentoo the upstream ./configure options are exposed to users, occasionally causing grief).
That they shouldn't be lumped in with the binary distros driven by release cycles and package freezes — they're the least likely to need an intervention from upstream.
Yes, certainly. My point was "if everyone did as Debian does, publishing software would become an enormous chore". I didn't mean to slight Gentoo/FreeBSD - or, for that matter, Red Hat or the others.
I've also brought up a counter question that people seem to not be able to answer: How do you get a bad Debian Developer fired?
It seems once they get in they're in for life. Yet, some of the worst DDs who crap on programmers seem to somehow get in charge of projects they actually hate. If they hate it, and they're breaking the software because of this, then why can't I, the original author, get them fired.
At an even simpler level, why can't you report bad DDs and have them reprimanded or taken off the project? That alone would bring out some better responses.
"The Project Leader's Delegate(s) may choose not to admit new Developers, or expel existing Developers. If the Developers feel that the Delegates are abusing their authority they can of course override the decision by way of General Resolution - see §4.1(3), §4.2."
Although my guess is that they're not going to kick anyone out because of your ranting.
Just remove the community from an open source community and things will start happening FAST.
Since, most people reading this thread are truly influential can't you guys talk with canonical and fork Debian under the Ubuntu project? You could model a community around how HN runs and vote things organically into existence while keeping a high level of quality. Instead of a rant match between a bunch of egos.
If you think about it the HN model is perfect for such stuff. If and only if you attract the right audience, but your work already reaches them!
Have you ever considered doing that? Or is there something wrong in my suggestion?
Have you seen how many packages there are in Debian/Ubuntu and how many Debian Developers there are? Forking Ubuntu entirely away from Debian would be a massive task and would need a huge injection of skilled people.
(Also internet voting for things leads to a system that encourages gaming the votes, see digg ;)
What I meant was inviting the best of those Debian devs to start afresh with the same code and create something even better under a new system.
You could always make voting tiered and restricted like stack overflow to avoid this... Moreover, if you attract just the right kind of people then the community will start moderating itself and keep the fluff at bay.
what are you trying to achieve with the voting? and what is the incentive for volunteers to put hours into packaging work if they're being motivated by votes rather than their personal interests?
A real democratic community where muscle flexing doesn't work and people can't exclude PHP from a package because it is "impure". If their big idea gets accepted they can collaborate with others to make it.
This significantly increases my respect for Zed Shaw.
Yes, he wrote an offensive post crying for blood, but after he had a chance to cool down, he used his own fame and audience to exhibit a well-reasoned response from someone who disagreed. That's a very adult thing to do. In some ways, it's actually better than an apology.
He reacted in the right way, but on the whole my impression is negative. I'm a bit disappointed, because most of Zed's previous rants were humorous, amusing and well researched. But in this case he didn't put any effort neither in research nor writing. He'd stumbled upon a dependency bug and, instead of reporting it, he for some reason concluded that it means that Debian is evil and everybody should boycott it. Weird.
PS. Excuse me, there was one amusing paragraph in the rant. The one in which he equaled Debian, the most independent and free software obsessed distribution out there, to Microsoft.
He didn't just stumble upon an overlooked dependency bug — the Debian maintainers intentionally broke their Ruby package years ago because of the legal problems they imagine to exist with using OpenSSL.
I don't think it's so out of bounds to compare Debian, the most copyright-license-obsessed distribution out there, to Microsoft.
Maybe it's a name problem. It was said ruby-full provides the full Ruby language, while ruby provides the export-restricted version Debian has to distribute in order not to have police officers knocking down doors. In Python's case (sorry, I am more familiar with Python) there are python and python-minimal packages. They may or may not mean the same as ruby and ruby-full, but their names communicate a similar intention.
While "police officers knocking down doors" over crypto export restrictions do not exist, that's not what Debian's wankfest over OpenSSL is about.
They think that the advertising clause in the OpenSSL license makes it impossible to use with any GPL programs — despite the fact that the OpenSSL developers think it's fine as a platform library and tons of upstream developers of GPL software choose to link against it. In Debian's world, they'll only allow you to use it if you get every contributor to agree to a special exemption clause appended to the GPL.
Through their absolute fealty to the most draconian interpretation of the letter of the law, Debian does more to further the cause of software patents and non-free licensing than any other organization. They choose to demonstrate how idiotic such ideas about IP are by implementing them to their fullest — by being idiots.
> Debian does more to further the cause of software patents and non-free licensing than any other organization.
Wow. Really?
> They choose to demonstrate how idiotic such ideas about IP are by implementing them to their fullest — by being idiots.
From the guidelines:
> Be civil. Don't say things you wouldn't say in a face to face conversation.
> When disagreeing, please reply to the argument instead of calling names. E.g. "That is an idiotic thing to say; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
I for one do not care at all for your rude name calling.
For what it's worth, I'm not particularly fond of debian-legal either, but it's entirely possible to express that disagreement without calling everyone who does not see the world as you do "idiots".
So who else is out there doing the work of enforcing American software patents on the users of the world? Even the BSA doesn't do that! Apple isn't out there enforcing their patent on the truetype hinting bytecode interpreter, but Debian refuses to ship a full version of freetype. The DVD-CCA gave up years ago, but Debian still won't ship a DeCSS implementation. Fraunhofer/Thomson/MPEG-LA only really care about companies shipping hardware, but Debian cares more about FUD and promoting OGG than actual use.
None of this shit matters at all when shipping source code, and binaries only matter if both parties are in the US. But the Debian project is out there with jackboots on, doing what they can to take useful freely-licensed software out of distribution. What other organization is doing anything like that?
I'm sorry that you find yourself so wrapped up in such an organization, I did not mean to insult you directly, but rather the ideology y'all are applying to make my world a worse place to live. And I would be far more acerbic in a face-to-face conversation.
You didn't understand my line of argument centering around idiocy (should have used fewer anaphora) — my point was that the Debian people know that they're being idiots, and that it's the purpose of their actions in this squabble. We all know that software patents are stupid, but Debian's approach is to show the world just how stupid software patents are by fully respecting them, implementing the letter of the law until it is repealed. I think that's a useless and infuriating course of action.
With regards to the legal stuff, I simply don't know. One of the things that bugged me about debian-legal were all the people convinced that they did know it all. I'm not a lawyer and neither are most people there. Neither are you or the OpenSSL guys either, though, as far as I know. My firm conviction is that most "open source legal debates" are essentially the blind arguing with the blind about various painters. Although, of course, many real lawyers are also so vague and non-commital in what they say that they're not much use either, so I tend to just want to stay as far away as possible from that kind of discussion.
That said, one thing I don't agree with you on is that "well, they probably won't notice / bother us, so it's ok to skirt the letter of the law". I think that's not really the right attitude either. Debian makes some strong commitments to shipping free software that people can use and redistribute as they see fit, so I think they have to be cautious at times.
I am not a part of Debian any more. I moved on to being simply a user (and bug reporter) of Ubuntu, which I think gets some things right that Debian didn't. I just don't like the "you fucking idiots" style of debate.
"ruby-full" did not exist for a long time, nor does it still provide everything in the normal distro. So far as I know, that is, I may be wrong since I stopped paying any attention to what Debian does a few years ago.
Only Debian considers it to be a problem for GPL software to dynamically link with system versions of OpenSSL. They be loud and obnoxious about it, but they really are the only ones who are stirring up shit. It's only possible to be incompatible if the GPL software ships with a bundled version of OpenSSL and doesn't append an exception to the GPL.
The OpenSSL project does not consider it to be a problem at all.
The upstream authors that simultaneously link with OpenSSL and use a GPL license obviously don't think it's a problem.
I did read it and I see that they are aware that their advertising clause causes problems for distribution and I see them recommending against making GPL software that links to OpenSSL. gem is GPL and links to OpenSSL.
I researched it plenty, and since your comment can't point out factual errors in my post, I'll just assume you're a hypocrite.
And yes, they embrace and extend. Embrace is taking the package in the first place. Extend is carving it up and patching it so that other companies that choose Debian are forced to either work around their quirks or accept them. That's the exact classic definition.
Unfortunately this research isn't visible in your rant, and it's not about factual errors. I didn't notice any effort to understand the situation better, for example by speaking with people involved (like the developer in question). But even if you did that, it looks like you intentionally avoided presenting the other point of view, instead of that you assumed upfront that the only reason is pure evilness. This is simply not a very convincing argument.
If you posted this at oppugn.us I wouldn't say a word, but I assumed that sheddingbikes.com is a place for more polished stuff.
PS. Debian is a loosely coupled group of more or less skilled volunteers with very little oversight and no business motivation. Debian has its flaws, but I see nothing in common with Microsoft.
But seriously, all distros patch things, they have to to make them work well together on the platform in question or to get the features/fixes they need. Look at how much RHEL patches the kernel, or Ubuntu patches GNOME.
Red Hat backports new drivers and features to ancient kernels because their customers use binary drivers, and Linux does not maintain a stable ABI. It's a shitty but completely respectable position to be in.
Canonical forks Gnome because Novell and a cadre of adolescents in western europe still technically control the project. Ubuntu will win eventually and this will stop being an issue.
Sane distros patch upstream just enough to make the software build and work. Debian does it to fulfill their ideological goals.
RH ships older kernels because they release relatively infrequently, and they've had time to QA them (the RH kernel test suite is huge and they run considerable stress tests). They backport features and drivers and fixes because their customers want the stability of well QA'd kernels and the support of newer server hardware and the benefits of fixes made later. One of the older RHELs even went so far as to backport entire subsystems from 2.6 into a 2.4 kernel because they felt overall 2.6 stability was insufficient for their needs.
Specific grips with your assertions aside, I think you are too quick to dismiss the ideological goals of FOSS projects - the entire FOSS ecosystem is afterall founded on some pretty seriously ideological goals, particularly Free Software. Open Source exists to dampen these goals and I suspect that a lot of folks now involved in this world are just interested in forking ruby software from github to run on their Mac ;)
Disclaimers: I own a Mac, but Linux has been my desktop/server OS of choice for the last decade, and I work as a sysadmin for a Linux distro company. I also write some software that's packaged in most of the distros now, so I feel self-entitled to see this from several very relevant perspectives ;)
> The one in which he equaled Debian, the most independent and free software obsessed distribution out there, to Microsoft.
Debian fails to do step 3. Microsoft's routine is "embrace, extend and suffocate" while Debian will never go beyond step 2. And they have the license to keep them honest.
An apology to who? I spoke my mind and made what I thought were valid points and I still stand by them. Debian is abusive to developers who create the software they need. It's only a matter of time before the programmers making their supply chain of projects declare enough.
As a good reference for the exact type of behavior I'm talking about, see this:
You spread mistruths about Debian with your various "business" comments. That in and of itself merits an apology. You can't just go making stuff up about people because they irritate you.
Also, from everything I can tell about your original post, you had a (well known) problem with Ruby gems on Debian, not with something you wrote. I can understand being irritated about that (Debian is not blameless, obviously), but there are jerks everywhere, and also an awfully lot of nice people in Debian too. Your lynch-mob mentality (seo tricks, in-person confrontations, etc...) reflects very poorly on you and is extremely unlikely to produce anything approaching positive changes.
If you don't like the freedom others have with open source licenses, why not just go back to making proprietary software where you won't have the problem. Freedom means that people sometimes do things you disagree with (even vehemently so), and if you can't handle it, then perhaps it is simply not worth it.
Debian is not abusive, some DDs are unfriendly some of the time. Some mistakes have been made. This isn't some conspiracy to ruin your rep.
How about users/sysadmins "rise up" against ruby/python/php for having module distribution/loading systems which in no way try actively to be easy to package well?
Tell us about the changes you are going to make such that all gems/eggs are automatically packaged for RHEL/Debian/etc so the overhead for DDs, and consequently their opportunity to confuse things, is near zero. That's the outcome we need. Are the languages prepared to make the changes necessary?
We're not going to cripple our modern programming language environments to suit an outdated system designed around mutually-exclusive soname dependencies, and we sure as hell aren't going to prostrate ourselves as a community before your baroque unnecessary social process.
It's not just us affected whippersnappers causing problems — even the enterprisiest Java communities have given up on your packaging model.
IMHO it's difficult to say "better technically" - for one thing portage is much looser than dpkg. Depending on your goals that may be better or scarier! ;)
So you're not prepared to change anything? Even if distros make changes as well? Why are these two groups not working together to enable magic for their users?
Why would it be so bad, for example, to have something like this in a python script:
Of course this immediately opens up a veritable hydra of questions and corner cases and other considerations that need to be made in designing such a facility, but that's why there are smart programmers and smart distro makers out there :)
I think it's fairly clear that there are grumpy, recalcitrant, belligerent people on all sides of this argument, and the people who lose most are the users that everyone claims to care about. As a user I feel that is deeply tragic and I feel like we have all failed.
Is precisely the feature I love most about rubygems, and would love to have in Python. It's also a feature that Debian goes out of their way to eliminate because it violates their precious FHS, apt can't handle it at all (they get around that for important packages by mangling the names), and superficially overlaps with their 'alternatives' system.
Where did you get the idea that I didn't want it?
Unfortunately there's no implementation path to make it possible on Debian's side, no matter what the language communities do to compromise. apt can't handle it technically, and their release cycle process can't handle it socially.
I got the idea because you seemed to react in a way that suggested you thought any language changes to support better/easier packaging was "crippling".
I'm not a skilled packager, so I can't get into a deep discussion of the parts that are missing on both sides, but it seems fairly clear that parts are missing on both sides. Perhaps it will take the work of, say, the ruby and ubuntu communities to demonstrate the change is possible and hugely beneficial for users, and encourage its adoption in Debian?
Personally, I don't have a fundamental problem with a distribution (even a popular one) refusing to package something for their systems that they think is awful.
Sometimes the easy choice is the wrong choice. If you just step back and say "well, they want to eat every meal at a fast food restaurant I guess I better make it easy for them to do that" then you are an enabler.
All that said, they should get off the fence about it. If they don't want PHP development beyond the web on Debian they should put that in a policy somewhere and direct people to it.
I didn't write it, Ersek, Laszlo did. That's how sheddingbikes works. Rather than comments, people can send responses as a post and if it's good I post it.
Sadly, it's not frequently that people send in a good response.
Like his message to Zed, it's clear, concise, and seemingly accurate. It also includes a wonderful and well commented example program in expert idiomatic C showing signal handling. I hadn't even known comp.lang.c was a going concern!
It's exactly the sort of quality code I'd expect from someone who writes such good prose. While I'm sure there are some examples of good prose writers who can't code, are there any definitive examples of good C programmers who can't write? Or is this just a "true Scotsman" problem?
I still think my point at http://news.ycombinator.com/item?id=1735344 is important. If Debian didn't throw away unit tests, a lot of these integration errors could get caught automatically.
Actually, I really agree with you here. In fact, it got me thinking about sort of a protection clause in licenses along these lines. Where you can say, "This software is BSD licensed, providing you follow the guidelines in the PACKAGING file."
Then, any OS distribution would be required to follow your wishes or not include your software. If you want unit tests, they include them. If you want all of it, or parts of it, they do it. If they don't want to or can't then they don't adopt your project.
I'm currently just figuring out how to word the license that way so it'd still work.
That license would not be "BSD", and what it was likely wouldn't be blessed by FSF/OSI/etc. (it doesn't meet the Open Source Definition, http://www.opensource.org/docs/osd and it’s probably not GPL-compatible), instantly making it suspect to lots of people.... Crockford got flak for adding a “The Software shall be used for Good, not Evil” clause, after all.[1] That would make it impossible for your code to be used by many open source projects.
[1] The FSF says “This is a restriction on usage and thus conflicts with freedom 0. The restriction might be unenforcible, but we cannot presume that. Thus, the license is nonfree.”
Sounds like you want a license where you get to dictate exactly how any downstream user reuses your software, down to the details of the packaging, and prohibit modifications/forks/removals/etc.? But that's not really an open-source license at all, then.
The whole point of open-source software is that I can take a thing, decide that I only want 50% of it, rip out the other 50%, add on a bunch of new stuff, totally change some of the remaining stuff, use it for a new purpose, package it in a new way, undo a decision the maintainer made that I disagree with, etc. If you don't like people having that freedom, open-source just doesn't seem like the way to go. It sounds like you want a "freeware for verbatim distribution" proprietary-but-no-cost license.
> dictate exactly how any downstream user reuses your software
I agree with your post. It's also worth pointing out that if someone abandons open source licensing, one thing I'd put in my licenses - way before we talk about fiddling with the path layout and such - is that the software can't be used by people I find reprehensible: neonazis, repressive governments, and so on and so forth.
Of course, I prefer freedom to that kind of licensing, so I just live with the knowledge that horrible people may use things I wrote.
The people you harm by restricting neo-nazis from using your software aren't neo-nazis, but everyone else who has to pay for lawyer time to review your custom license before they can use it. Or what's more likely: aren't going to use it at all once they see what sort of license you have.
Not to mention that actual neonazis will probably not give a great deal of thought to violating said license, meaning you'd have to have a way to monitor usage, and then go to court to stop them. All in all, a hassle that's not worth it.
Firefox would be an obvious example of that. All that happens is that Debian will rename the package and ship it anyway, and users lose even more than they did before. Good job! ;)
It's not.
A number of months ago, I tried getting trimage (a gui image optimizer, http://trimage.org) into debian. Since I already had a working Ubuntu PPA, I figured it wouldn't be too hard. Packaging instructions for debian are available at various official websites, but contradictionary and they all seem to presume you have packaged for Debian before. Jargon like RFP (request for packaging) and ITP (intent to package) is thrown around frequently without explanation.
Luckily, there is debian-mentors, meant to help upstream developers with becoming a sponsored maintainer. Most of the debian-mentors site links to outdated packaging instructions, using which will mean you will be ridiculed on the way-too-hostile mailinglist. Trying to do 'the right thing' is almost impossible, as most of the feedback will depend on the personal opinion of the person responding. I suspect this is because they, too, don't know which packaging instructions to use or point to.
Trying to get my application into debian has been nothing but a massive, timesinking frustration, and I wish that wasn't the case.