"Richard Stallman, revered by some as a genius (after all, he won a McArthur “genius” grant in 1990) and by others as a crackpot"
When I first heard him speak many years ago, I thought he was a real crank. My negative thoughts centered around:
1 - How can we build the next Microsoft without true ownership?
2 - Does his model of thinking demand that 100% of the population be technical enough to troubleshoot their computers?
3 - I can see people writing software for love, but who writes all the documentation?
As the years go by, he's one of the few people who sounds less like a crackpot, even though he hasn't softened his extremism. With the current state of patent trolling, it's getting harder to create the next Microsoft. Improvements in GUIs is taking some of the issue away for #2. But I still haven't figured out #3.
> I can see people writing software for love, but who writes all the documentation?
1. People like me? :) I genuinely love writing documentation. Though I should mention it's easier to write books/tutorials than to write detailed documentation of the software you are yourself not writing, which brings me to point 2.
2. Writing documentation is very much a part of software-writing. It's usually best to do write documentation as you're writing the software... I haven't met anyone yet who really hated the process, so I wouldn't consider this to be a big problem at all.
I too write documentation. Not exclusively, but in my day job I often write manuals and other documents for our software, and I've done documentation work as a volunteer for Project GNU.
It's no more strange that someone would enjoy writing documentation that it is that someone would enjoy writing software, though just as non-developers don't understand the joy of programming, I imagine that non-writers don't understand the joy of documenting.
So a question in return... Do you share my belief that documentation tends to lag in most projects? And if so, is the bottleneck not enough documentation writers, or not enough engineering time and attention? I've assumed it's the latter, though it could be the former. Or is it something else?
Do you share my belief that documentation tends to lag in most projects?
Absolutely.
I suspect that the number of people interested in writing software documentation is fairly small: they have to have enough knowledge of software engineering to be able to understand what they are writing about, and they have to be good writers. Anyone could learn software development, but not everyone does. And anyone could learn how to write well, but not everyone does. So the set of people who learn both is even smaller.
On commercial software engineering projects, my experience is that documentation of any sort is made as much of an afterthought as possible, if even that. Unless there's some business case (i.e., obvious money) that comes from spending time on documentation, then it doesn't make it very high on the priority list. Which is unfortunate, because as a software developer, I've wasted a lot of time figuring things out that should have been documented. So money can be saved later on, even if no money is "earned" up front.
For free / open source projects, the story may be different. There's not necessarily paid engineering staff involved, so if documentation doesn't get written, I can only presume that the developers either didn't want to, didn't know they should, or felt incapable of writing it. I find it hard to imagine taking a principled stand against having good documentation.
BUT... in my anecdotal experience, I've encountered volunteer open source software developers who in fact did seem resistant to accepting offers of volunteer help with documentation. So I'm not really sure what's up with that.
It was not meant as an attack at all. It just seems to be a very under-appreciated skill. I've yet to see a firm whose documentation is current more than 6 months after a major release. If you're able to keep up, you're more in the minority than your realize. :-)
#3 is being crowd sourced already for many for profit companies and open source projects via wikis, blogs, forums, videos, podcasts, and Q&A sites populated primarily by volunteers. Particularly with games, documentation is sometimes intentionally not included to allow "explorer" players debate, theorycraft, and publish knowledge about the game for fun, notoriety, and sometimes profit.
We've also seen further pushes to higher level languages, automated testing, improved version control systems, better and more accessible bug and feature tracking products that begin to take the place of official documentation or at least let it be automatically generated.
I also don't think we've reached the end of innovation in this area of self documenting code plus incentivized crowdsourced documentation. Slow incremental changes are eventually going to make that current help link at the top of your software app extinct, or at least look like a dinosaur compared to the elegant evolution that takes its place.
I'm with you on self-documenting code, but what about user documentation, and documentation of APIs?
Now I'm not saying the current model in for-fee software is right. I just wonder, "If it's this hard when you're paying people to do it, how about when you're not?"
I hope to be proven wrong! :-) My company has a great tech write, but I live in fear of the day when someone buys one of his screenplays and he doesn't need us anymore...
Aren't there companies like mashape for documentation of APIs (or at least through their software/proxy)? And if you decide to charge for it, ~20% goes to them. Works for me, but I don't know if that is the cool thing to do…
The thought process came to me many years ago when Microsoft was an example of a startup that built itself from scratch and was very current.
I've come around to broader thinking since then. And Microsoft has changed some too. But it has gotten harder to create companies from scratch due to restrictions on developer freedom. (Patents) There are other reasons that have made it easier, but those are tangential to RMS's topics.
RMS is extreme, but your questions don't seem that hard to to imagine answers to.
1. Why would we want to do that? What problem does creating the next Microsoft solve?
2. I have never heard him claim this. Free software means that you have a right to troubleshoot and resolve problems yourself if you want... not that diy is the only option
3. Why can you see one, but not the other? Some of the best documented software is foss. For example, Its hard to beat Emacs documentation.
It doesn't matter how good the man pages are, I can't give emacs and latex to my mother and expect her to produce a document. In general, FLOSS really sucks at supporting nontechnical, mainstream users.
I understand your point, but I was talking about documentation, not ease of use (sometimes they go hand in hand, sometimes not). Also to further my point about docs in emacs, emacs goes waay beyond just a man page, documentation is baked into everything. Everything is in there... minimal googling required. If you can't tell... im still high on my first few weeks playing with emacs, plz excuse my cool-aid stains.
1 - At the time, creating the next Microsoft meant creating a company from scratch, which built products that the whole world uses. There are many economies of scales that great software companies can achieve.
2 - He didn't claim this explicitly. It was my interpretation of the results of everyone growing their own. I'm less convinced of this today.
Probably both. Like a lot of other speakers, Stallman has a few canned speeches. He asks the organizers which one they want, and he gives it. It probably evolves over time, but the differences are minor.
The issues Stallman talks about have not changed much over the last 20 years, so his speeches haven't either.
I have to admit before the whole PRISM story I didn't think much about Richard Stallman and thought he's too extreme or delusional. After PRISM however I realised he was right all this time and I was just too stupid and blind to see it. I'm going to read more of his notes. Very few people have what it takes and are willing to pay the huge and continuous cost of rejecting proprietary software/technology. But he has been standing by his principals for a lifetime and I respect him for that.
Read this and talk about ominous: http://www.gnu.org/philosophy/right-to-read.html I think rms has other interesting articles on the same subject but I fail to find them right now, I now I read a few back in the days when I was diving into FLOSS.
I attended a talk by Richard Stallman about two years ago, and it revolved around the same ideas. While some of his ideas are a bit too extreme for my taste, e.g., when a guy asked how to make money by building Open Source software he replied something like "get another job", I think that many of them are inspiring. Such as the ones about proprietary formats and owning your own data.
I attended the talk covered in this article, and someone actually asked him a similar question there.
His reply this time is that, personally, he had never made more money in his life than when companies paid him to fix or improve open source software. And I can see his point!
It may not be common, but there certainly plenty of organizations that either have business interests aligned with open source technology (e.g. 10gen, MySQL AB), have open source ingrained into their culture (e.g. Wikimedia Foundation, Mozilla), provide consulting/training services around open source (e.g. DataStax, Elastic Search, LucidWorks), or simply use open source so heavily that they need to pay people to improve it (e.g. Intel, Google).
And then, there are plenty of companies (like mine, http://parse.ly) that take the business perspective that anything that isn't core to our business / competitive advantage not only can, but should, be open source, eventually.
Getting a job working on open source isn't some fringe thing anymore. If it feels that way because your employer doesn't allow open source work, you may want to get the heck out :)
I suspect if you really, truly believe what Stallman says about freedom, you would be hard-pressed to find a job in any field. Many of Stallman's ideas echo what Ivan Illich had to say in Tools for Conviviality (though Illich understood that sometimes, some systems were "closed."
For example, let's say you want to be a carpenter. You would need "open source" tools that you could hack and fix, or you'd have to simply make your own from scratch. I realize such things exist, but you immediately put yourself at a disadvantage because you'll pay significantly more for your tools than a carpenter buying equipment at Home Depot.
Note, too, that I'm not criticizing Stallman's perspective here (I am sympathetic to it)--I'm simply thinking about the ramifications.
His concerns are about law and policies constraining freedom, not about building things from scratch. You need not write your own compiler to be consistent with the principles he advocates - Stallman would say you're fine using gcc, because it is legally open for the "four freedoms".
And physical goods are already "free" in the Stallman sense, if not patented or subject to restrictive contracts. Both software and hardware have use-value and costs to produce, but only the physical goods have intrinsic market value.
The hammer needs materials and significant per-unit labor as well as intellectual contributions, and in the absence of IP, has market value approaching its intrinsic (use) value. Commercial software that is published rather than used only in-house (i.e., monetized on a licensing model) has market value only because of artificial scarcity, and could hardly exist in a "free market" (without state-enforced monopolies).
His concerns are about law and policies constraining freedom, not about building things from scratch. You need not write your own compiler to be consistent with the principles he advocates - Stallman would say you're fine using gcc, because it is legally open for the "four freedoms".
Yes, that's right. But what about, say, an electric drill with proprietary schematics? While I may be free to modify the drill as I see fit, it wasn't necessary built for that purpose. Additionally, I can't modify the drill a little bit, and then start producing them myself (I suspect the original manufacturer might have something to say about that).
Perhaps I'm splitting hairs a bit, or thinking too deeply about it, but the topic of tools interests me.
'e.g., when a guy asked how to make money by building Open Source software he replied something like "get another job"'
He's right in a way, don't you think? Let's look at it in another way: Open source is ostensibly about altruism isn't it? You get side benefits like free code review (this is arguable to a degree since edge cases/difficult issues don't get a lot of love), but in the end, it's about giving your work away for the benefit of people you'll likely never meet.
So then how do you turn altruism into a business? Some people have (charities are big business these days), but that isn't in the true spirit of altruism. So those who do build open source software without ulterior motives are destined to break even at best.
Open source is ostensibly about altruism isn't it?
No. Free Software (Open Source misses the point[1]) is about giving users their four freedoms. There's nothing in the philosophy that implies that you shouldn't charge for it.
Personally, my salary - and of the other developers at the company I work for - is paid for writing Free Software, some of which is publicly available, some of which isn't.
"Since free software is not a matter of price, a low price doesn't make the software free, or even closer to free. So if you are redistributing copies of free software, you might as well charge a substantial fee and make some money. Redistributing free software is a good and legitimate activity; if you do it, you might as well make a profit from it."
Most contributors to major free software projects, like the Linux kernel, are paid developers working for corporations. So I guess it's not that hard to make money on free software.
You can't sell services to everything. If you want to sell support for your open-source product, then you get more money (from more support contracts) by deliberately making the interface obtuse and hard-to-use.
The GNU manifesto says that eventually "There will be no need to be able to make a living from programming", but it doesn't give much advice on what to do until then. In the future, the software that runs the asteroid miners should be open for the public to see, but in between there and then there'll be private companies trying to mine the most asteroids, keeping their software proprietary as they do.
This was a terrible piece. Why/who think Stallman is a crackpot? And what is up with this snide editorializing?:
'“Almost everyone in the world using proprietary software is also using propriety malware,” said Stallman, who looks every inch the part of a hactivist with his long mane of graying hair.'
I actually bust out laughing when I read that. Journalistic standards, please.
When I first heard him speak many years ago, I thought he was a real crank. My negative thoughts centered around:
1 - How can we build the next Microsoft without true ownership?
2 - Does his model of thinking demand that 100% of the population be technical enough to troubleshoot their computers?
3 - I can see people writing software for love, but who writes all the documentation?
As the years go by, he's one of the few people who sounds less like a crackpot, even though he hasn't softened his extremism. With the current state of patent trolling, it's getting harder to create the next Microsoft. Improvements in GUIs is taking some of the issue away for #2. But I still haven't figured out #3.
Edited for formatting