The cost of living is highly dependent upon the standard of living. Those with a lower standard of living spend less money and it filters down through the whole system. So maybe you can buy a meal for $1 rather than $5, but everyone who lives there doesn't have running water. If you gave every body running water, the cost of living would go up. If you gave everyone the luxuries that Americans enjoy, it would cost as least as much as in the US.
You can't compare cost of living without comparing standard of living for the average person.
Sometimes I think people from "1st world" countries can't really understand what it is like to live without the opulence they are used to. Even people making minimum wage mostly have running water (hot and cold!), heat in their apartments (many even have AC!), sufficient clothes, and enough food so that they can actually have a choice whether or not to be obese. Most even have a few ridiculous luxury items like refrigerators, TVs, washing machines and cars (even if they aren't new).
Look at the people working in a factory in the US. Most of them are fat, right? Look at people working in a factory in China. ALL of them are thin. Trust me, food is the last "luxury" that you give up. This means that Chinese factory workers are living at a standard of living FAR below what most Americans would deem acceptable -- regardless of the "cost of living".
But the ISO 9001 standards aren't fixed. Basically you document what you are going to do, show that you've trained your staff to follow the process and show that the staff are following that process. You can easily do 9001 document control standards with a pen and a filing cabinet. Yes, there are some specific requirements: you must define a way to show that the currently accessible document is the most current one, etc. But 9001 doesn't require you do it any specific way.
In fact, if you simply buy a piece of software and say, "The software enforces the process" a good auditor (hah!) will fail you. The whole point of 9001 is to document a process, train your staff to follow it, and show that you are following it. You can buy a canned process, train your staff in that process, have tools to help you, show that your are following that process. You will pass 9001. But you will have a fucked up process because it almost certainly won't follow your company's natural workflow.
I suspect this is why the parent suggests that maybe looking for a tool rather than working on the process is a bad idea.
* About the "hah!" comment: I don't believe there exist good 9001 auditors. Or rather, if they exist, they don't work much. It is in a company's best interest to hire incompetent auditors. That way they pass the audit. I say that having done the job myself once a long time ago:-P
Simplicity is a bad word in this context, as you point out. There are two concepts that it points to which are always getting confused.
Ease of learning: Something that is easy to learn lacks conceptual complexity. It is easy to understand quickly and it is easy to remember after being exposed to it only a few times. The downside to ease of learning is that you usually can't do things that are conceptually complex.
Ease of use: Something that is easy to use lacks operational complexity. It is easy, fast and convenient to do what you want to do, no matter how complex. The downside to ease of use is that the ability to do complex things quickly usually requires an interface that is difficult to learn.
You can optimize for either of these kinds of simplicity (ease). Your interface can be unnecessarily complex in either or both categories. Good software chooses the least complex solution, while still optimizing for the type of simplicity that is required.
It is quite common in the financial world to sell an asset early for a smaller sum rather than wait for its full value to appreciate. There are several benefits to this. The first is that you get the money now. You may need the money to pay for things like rent and food. A million dollars ten years from now does me no good if I starve to death today. The second (and more important) is that you can offload risk to another person. Your song/book/software *might* be worth millions or it might be worth nothing. Sometimes it is better to opt for the security of a real paycheck rather than hope you will strike it rich sometime in the future.
As an author of software I have never regretted having the option to transfer my work to others in exchange for money. Although I made much more money for others than I made for myself, I don't think I was financially taken advantage of. The security of the paycheck was well worth it. These days I wouldn't transfer my copyright simply for money, but that's more an issue of control than anything else. I was never happy with *how* my work was used and how the customer was treated. By retaining the copyright I have more control. But I also don't make any money doing it;-)
In language courses it is quite common to "teach to a test". The way I've seen it, they give the students huge, impossibly difficult passages to read. Then they have a series of very difficult questions with multiple choice answers. Then the teachers teach the students how to match the questions to the passages and deduce the answer -- all without understanding either the passages or the questions. These students can pass extremely difficult standardized tests (which are all of this format, because marking essay questions takes much, much too long and is considered too subjective). But even though they can pass the exam, they usually can't speak the language at all.
A university prof *can* pretty much fire their students. They do so by giving them a failing grade. Enough failing grades and the student will be suspended for a year (and probably won't come back again). I think this is appropriate. A university student should be there to learn and the professor is simply a resource. A prof can be good at teaching, but the primary motivation needs to come from the student, not the professor.
In high school and lower, I believe things should be very different. A teacher's role is *not only* to present the material, but also to teach the students how to succeed. High school material in the west is ridiculously simple. The average person can learn it relatively easily. Those who can not learn suffer because they either don't know how to succeed, or don't want to succeed. Some people's lives are so traumatic that any thought of success escapes them completely.
If I were to teach only to my students who meet me half way, I'd have virtually nothing to do. I'd throw them new material and simply say, "Here, go learn this". And they would do it. In fact a lot of teachers do just this. 20 percent of the class is happy as clams. 70 percent sits in stunned silence and 10 percent go ape-shit insane. These last 10 percent are labelled "trouble makers" and said teachers do their best to get them run out of the school. This is a crappy way to teach.
While I am hardly an experienced teacher (I still pretty much suck) I can try a different approach. The students who meet me half way will learn the material no matter how good I am, so instead I try to get them to focus on their areas of weakness, rather than their strengths. Quite a few of them hate high school, so it's better to help them with social skills and improving their happiness. For the stunned, silent students I try to show them a method where they can easily succeed at academics. Success breeds success, so I try to catch them on a good day and get them to try. For the last 10%, I try to give them hope. I hold the door open as long as I can and encourage them to come through. Then I wait for them.
My classes work best when there is something for everybody. Disruptions occur when people get bored/lost/abandoned. The top students get an environment where they can study when the bottom students are engaged and cooperative. The bottom students get opportunities to succeed when the top students haven't moved completely out of their reach. It's a delicate balancing act.
The problem with frameworks is that they dictate design decisions. This can save you a lot of time up front because you don't have to rough in your design. You save a lot of coding effort. But if the project runs for a long time, your design will almost certainly move away from the original design. With a framework, you have 2 choices: write big ugly hacks to work around it, or abandon the framework. Since the second option is very time consuming everyone picks the first one. This results in code that slowly gets cruftier and cruftier. Eventually you lose all the time you gained up front and have a crappy code base to boot.
If you write your own, you will probably be reinventing a lot of wheels as you start. But you can easily refactor the design as you go, keeping your code base clean.
Having said all that, the number of teams that actually refactor their design as the go is vanishingly small. Most end up with crap no matter what they do. So, one might say that frameworks are generally useful. I often wonder if extremely minimal frameworks would be more helpful. The would contain only enough to get you over the beginning hump, but allow you to easily modify it as you go.
Personally, I have very few real problems with the legalization of marijuana except for one. The preferred method of ingestion is smoking and smoke is very rarely contained. *I* don't want to smoke marijuana whether directly or through second hand smoke. Even if only legal in one's own home, I have enough problem with people smoking cigarettes on their porch/balcony and having it waft through my bedroom window. As a recreational drug, someone's enjoyment of it shouldn't result in me having to smell it. As stupid as it is, the current illegal status of marijuana makes conversations like, "Would you please not smoke a joint right under my bedroom window" much easier than its tobacco oriented counterpart.
If it stops others from implementing this abomination, I'm all for it. As embarrassed as I am to admit that I use FB I have to say that the News Feed is horrible. I guess they were trying to find a way to show me what I'm interested in without showing me a whole bunch of garbage. They failed utterly. News Feed has some random kind of order that I can't fathom. It mainly shows me things I've already seen without showing me new stuff. And it seems I can't permanently turn it off.
At first I thought it was almost impossible. But then I started to think about a few AI vision algorithms and realized that actually the technology to do this has been around for a long time. But I will say that the application is innovative (at least for me). I wouldn't have thought about doing it at all.
I'm curious. Who do you get for support for Microsoft products. Does Microsoft offer support? And by support I mean, if there is a bug in Word corrupting your mission critical documents, will they promise to fix it? And will they give you a projected time for completion on the work. And will they give you periodic updates? And will they send you a patched version as soon as it is fixed? How much does that kind of support cost? Are you sure it's really cheaper than an open source project?
And what happens when Microsoft "End-Of-Life"s a product? Can you get support from a third party? Can you develop internal resources to provide support and add small features? Or do you have to simply buy whatever Microsoft replacing it with, regardless of whether or not it fits your needs?
And when you say that finding people able to do internal support (I assume first level support, since you can't really do anything else with proprietary software) is easier and cheaper with more popular software, isn't this simply a training issue? Do you really have such a high turnover rate in your company that most of them were trained in using software at their previous job? Or are most of them trained at your company, meaning that it doesn't matter if it's the most popular software or not -- It just matters that you can find initial training at a reasonable cost?
Certainly I think it's a good idea to get support for software you buy. However, I have never worked at a proprietary company that offered anything resembling what I think of as support. "Support" in the industry means get the off the phone as quickly as possible because every minute on the phone eats your entire profit. Sure we did special one-off deals for customers who bought 10,000 copies of our software, but we gave them a bloody hard time of it. If they didn't threaten to not upgrade to the next version, they wouldn't get anything at all. We might fix their bug in the next service pack, or maybe not, at the whim of the program manager.
Real support, meaning having someone who is contractually obliged to help you when your software doesn't work for you only seems to be available for custom built software. And if you aren't getting source with your custom built software, you're getting ripped off.
Or at least that's been my experience. It would be interesting to see how your experience differs.
The problem with measuring the effectiveness of programming techniques is that it is very difficult. It is quite valid to say that there are few studies to back up the effectiveness of various "agile" techniques. But I will point out that this is true of every programming technique.
The problem with measuring this is that it is impossible to get a baseline. There is a huge difference in productivity based simply on individual talent. This has been shown. So you will need thousands of programmers to test any theory. Problems are also extremely variable, so it is difficult to measure productivity across different problems. You would need to solve hundreds of non-trivial problems to test your theories. Finally, objective code quality is an unknown. Existing metrics are well known to be bad at estimating real quality. Solving any one of these measurement problems would be enough to get you a PhD.
If someone could find a good way to test different techniques and provide statistically significant results, they would be rich beyond the dreams of avarice. You use a variety of different techniques, which I assume you feel are more effective (or at least as effective) as others. Check the literature. Do you have any proof other than your own (or other's) anecdotal experience to back up your opinions?
Unfortunately, with the current state of affairs, we are very vulnerable to methodology snake oil salesmen. Everybody wants the cheap cure-all. Every popular methodology has more than its fair share of such leeches. As soon as it becomes a buzz, somebody wants to make a buck off it. The truth is that there are a lot of individual techniques that are effective, but you are going to have to put effort in to evaluate them yourself. Try to keep an open mind and keep several hours a week available for training and exploring these possibilities. You won't be sorry.
This is a really good post. I wish I could moderate you up. Like some people, I've become less enamoured with the word "test" for unit tests. It implies that I am trying to find out if the functionality works. This is obviously part of my effort, but actually it has become less so for me over time. For me, unit tests are used for telling me when something has changed in the system that needs my attention. I liken it to a spider's web. I'm not trying to find all the corner cases or prove that it works in every case. I want bugs to have a high probability of hitting my web and informing me. When writing new code I also want to be informed when I make an assumption about existing code that is different from the original author. I think about my assumptions and try to write unit tests that verify the assumptions. This often fills out most of my requirements for a "spider's web" since when people start messing with code and break my assumptions, my tests will also break.
Finally, your point about documentation is extremely good. A large number of people, even if they are used to writing unit tests, don't understand unit testing as documentation. I've gone to the extreme of thinking about my tests as being literate programming written in the programming language rather than English. To this extent, I've embraced BDD and write stories with tests. For each story that I'm developing, I'll create unit tests that explain how each part of the interface is used. I then refactor my stories mercilessly over time to maintain a consistent narrative. However, I often feel like I want a "web" (as in TeX's literate programming tool) tool that will generate my narrative, but will still allow me to view the code as units (which is useful for debugging).
The problem is that "Agile" as a methodology means almost nothing. We value people over processes, etc, etc. It could be anything.
I've worked on a couple of very successful XP style projects. One was so successful that it surpassed my wildest expectations. We had good people on the project, but it wasn't much different than other teams I've worked on before. The biggest difference was an interest in the XP practices and a consistent approach to applying them. The more we did it, the more we learned, and the more successful we became. I can't really explain it well, but the more code we wrote, the rate at which we could implement functionality increased (exactly the opposite from other projects I'd been on).
But it's this not being able to explain our success that is the problem. I now know what a lot of people mean when they talk about hyper-productivity in "agile" projects. And after that wildly successful project I would look on in despair at other projects. Management would suggest that this project was successful too and I would have to disagree. I could point to places in the code where cruft was developing. "All code has cruft", they would say. But cruft slows you down. It makes you have to think hard about what you are doing. It makes you make difficult decisions about what you should be doing. Truly agile projects can't afford cruft. Think about how easy it is to write new code compared to writing code in an old system. Well, truly agile code is *easier* to code in than new code. And the more you write, the easier it becomes. You get more functionality, it's better organized, it's easier to read, it gets closer and closer to the real problem domain. And it even tells you (through "tests") when you use it improperly.
This kind of code comes from the dedication of the developers, I think. The "agility" doesn't come from avoiding overhead. It comes from constantly making things easier and easier. It comes from being sensitive and saying, "That bugs me" and improving it -- every single time. It comes from understanding the separation between the business side where the 80/20 rule applies and the technical side where the 80/20 rule means you're going into technical debt everyday.
I have no doubt that there are people who experience the "agility" that I experienced using a variety of different methods. XP isn't what made me "agile". It was more of a bootstrapping process that let me start understanding what was important and what wasn't. I suspect there are people who are more talented than me who can see that without being shown. But from experience they are very rare indeed. And unfortunately the vast majority of people believe that "Agile" means exactly the opposite of the discipline that is required to achieve it.
OO is a very important project which has done a lot to show people that open source software is viable for desktop environments. But, and I say this as someone who uses oowriter every single day, it should be replaced with something better. There isn't a single program I use that causes me as much grief as oowriter. I'm working as a teacher in Japan right now and making handouts every day for my students -- actually, at this point I think it might be better to say I'm writing a textbook. I use a huge amount of clip art and I'm switching between Japanese and English a lot, so possibly my case isn't typical. But my documents get corrupted weekly. Sometimes the pictures delete themselves. Sometimes the fonts decide to change themselves randomly. Sometimes the document gets so bad that the cursor randomly jumps around the screen. When I am making my exams (which are very heavy with pictures) the scrolling the document is so slow that it takes 10 seconds to get to the end of the page.
I have slowly been writing latex macros so that I can finally ditch OO (it's quite difficult given the number of unique formatting I have to do, from word searches to crossword puzzles to bingo boards -- all with clip art liberally sprinkled on the page). When I'm done I won't be the least bit sorry to see the back of OO. But not everyone can sit down and write custom latex macros to format their stuff. I'm kind of hoping that a potential lack of OO funding will remind people of other solutions like KOffice or Abiword (which aren't quite there yet for my applications, but noticeably less crufty).
What confuses me is this: isn't having a distributor dictate the price of an item to a retailer called "price-fixing"? Isn't is illegal in the US? If I understand correctly, Macmillan and many authors are upset that Amazon want to sell at a reduced retail price while still paying the *same* wholesale price. Shouldn't that be allowed in a free market economy (as long as they aren't selling below cost in order to force out smaller players)?
So why did Amazon have to capitulate? Clearly they have to buy the books at whatever rate the publisher wants. That's fair enough. But I can't understand why they can't set whatever retail price they want.
The trick is that "far-left" and "far-right" are simply inventions to keep people arguing about trivial matters. So occupied, the masses don't realize what is actually happening in the circles of power. It amuses me that American media is always so polarized. The even hire people to take up "far-right" and "far-left" stances and argue on camera. Given the vitriol engendered in their arguments, viewers mistakenly believe that the topics are important. This allows policy makers to carry on with their agenda without interference from the unwashed masses.
Not sure if you're trolling or not. But just to clear up a common misconception, the vast, vast, vast majority of manga is not pornographic at all.
Pornographic manga is definitely available in Japan, but not all of that depicts children. Pornographic manga is available in most book stores and as far as I can tell most of it depicts adults. There is definitely a sub-genre that depicts high-schoolers, but it is not the most numerous by any stretch of the imagination. As for manga depicting pre-pubescent children, I've never seen any in the shops. Probably you'd have to go to a specialty store of some kind. Where I live, I wouldn't have any idea where to start looking. Nor would anybody else I know around here.
Graphic novels are a ligitimate avenue of storytelling that is very popular in Japan. Equating them with child-porn is really way off the mark.
Having said that, my friend's niece is really into Inuyasha, so I mailed her the Japanese version of the first volume. I didn't realize at the time that there is a single topless picture of the main character (a 14 year old girl) in this volume. So it seems I am unwittingly guilty of distributing child porn into the US, to a child no less...:-P
The thing is the GPL isn't the "golden chalice" even for the FSF. That's why they have the LGPL. And nobody (that I've ever heard of, anyway) is going to criticize anybody for choosing another free license (like BSD) either. Choosing the correct license is a very important thing and every developer should think very carefully about it before they release. I can't tell you the number of times I've heard developers complain about being "ripped off" because somebody used their code in a "commercial product" without their consent -- only to find out that they had a BSD license. Or that they complain about being "ripped off" because someone charged money for their application without their consent -- only to find out that they had a GPL license.
People need to think about what they want to accomplish with their license. Sometimes something like BSD is the best. The advantages are wide adoptability. People can join your project easily. But someone may just stick your code in their own product. You'll be competing against yourself, but at a disadvantage since they can use your code and you can't use theirs. For a lot of stuff you don't care and BSD is great.
Maybe you care about end users being able to use the latest version of your code, but you don't care about unfair competition. In this case the LGPL is a great license. Anybody can use the code any way they want, but your users can fix bugs in your code or add new functionality, etc.
Maybe you care about making sure nobody can use your code to leverage an unfair advantage against others. Everyone who adopts the code in their program must agree to a common set of principles. This way nobody is at a disadvantage. The GPL is great for that. But remember that the more restrictive your licensing is, the less potential users you will have. And there is no question that the GPL is more restrictive than the BSD license. However, for the reasons above (and many others) a very large number of people think it strikes a very good balance.
Personally, I don't like licenses that are more restrictive than GPL. As a user as well as a programmer "free" (as in software) is extremely important to me. It's worth more than money to me. I regularly fix bugs and add features to code I use. And I value the ability to ask my friends to help me out when I can't fix it myself. When I have had to use proprietary software (both as a user and programmer) I have almost always been very frustrated with the lack of ability to fix my own problems. I've decided never to write software that is more restrictive than GPL and I wish others would do so as well.
Software patents were a problem then and are still a problem now. Patents have always been a trade off. At one time everyone making inventions hid their work through secrecy and obfuscation. This is clearly their right and in order to protect the upfront investment in research and development it was necessary. Otherwise someone could use the information that other people had developed in order to create a product without the upfront investment. They could then undercut the initial inventor.
The result of secrecy and obfuscation was that society couldn't build on top of new ideas. Progress could stall because only a few people knew how something worked. So a limited monopoly was granted to inventors in exchange for full explanations of their inventions. It was hoped that this monopoly would allow others to build on previous inventions and accelerate progress.
This is fine when we are talking about real physical machines. We aren't giving monopolies on ideas, rather their expression in physical form. In the world of physics, only certain things work for a given problem. For example with velcro the hooks have to be at a certain angle and the loops have to be at a certain density. Nobody can patent the idea of a hook or a loop. But a specific physical arrangement of hooks and loops with a specific application is patentable.
The problem with software is that it isn't constrained by physics. For any given problem there are many expressions that can work. Software *isn't real*. If my hooks and loops don't match up I can change the laws of physics to make them match. The work in developing software is *not* trying to discover the angle with which a hook must be made, but rather the sheer volume of describing the hook.
Because people misunderstand the purpose of a patent, they believe that patents exist to protect the upfront investment of development. In this case, if it takes a year worth of work to type in the description of my hook, that hook must be worthy of protection. It is, after all, a considerable upfront cost in my act of invention. But the *specific description* of the hook (i.e., the source code) is not what they want to patent. After all, they already obfuscate it and have a copyright for it. It is amply protected. What they want to patent is the idea of a hook for a given application. *All* descriptions of hooks for that application are now forbidden.
Now we could argue that some techniques are difficult to develop. This is true. But on a computer, all techniques are mathematical algorithms. These are not, and never were patentable. If we accept the argument that a computer program is a "software machine", then the patentable part must be the description of the algorithm in the computer. But this is already obfuscated, secret and protected by copyright. They wish a higher level protection on the concept itself. This is a problem because it has never been patentable (if you wish a reason, I direct you to read the original arguments given when instating the patent system).
Not only are software patents a problem, their very nature is what is causing "bad patents" and "money through litigation" schemes. Any software patent must, by necessity, by overly broad and provide an opportunity for abuse. Not only should software patents be disallowed, but also "hardware" patents that can be fully implemented in software. To do otherwise is to fly fully in the face of the original intent of patents.
Computerized health care systems are not designed for the benefit of hospitals. They are designed for the benefit of entrepreneurs.
Health care is a multi-bazillion dollar industry where information is managed via bearskins and stone knives. Development of an integrated computerized health care system will net the intelligent investor more money than even Microsoft can dream about.
This is the message that people I will call "serial entrepreneurs" pitch. Their intent is not to build such a system (that would be nigh on impossible given the absolute chaos of incompatible processes that currently exist in hospitals). They simply want to build a system that looks close enough that stupid investors will throw millions of dollars at it. The potential payoff is so big (seemingly) that people will keep throwing money at it even after said entrepreneurs have razed and burned a stack of companies.
Of course, eventually there *will* be a company that succeeds (mostly by accident). That company will run suspiciously like SAP where there will be a very complex set of computer programs designed to support an even more complex set of processes. These processes in turn will have nothing to do with the underlying business of providing health care. However senior management will be ecstatic that they finally have a unifying computer based process, and the only people who fully realize its true futility will be the people doing the work. They, of course, will be ignored.
In Japan sashimi is always served in sushi restaurants. A person may say, "Let's go eat sushi" and then at the restaurant end up eating only sashimi. But at a banquet sushi is almost never served. Sashimi on the other hand is virtually always served. A person would never say, "I went to a banquet and ate sushi" meaning that they ate sashimi.
Historically, sushi is a snack food. It's kind of an all-in-one meal since the rice is included in every bite. In a way you can think of it as a sandwich. In western culture, bread was once seen as the most important part of a meal. With a sandwich, you eat the bread with the meal. But you can also eat bread separately with the meal. You can eat a roast beef sandwich, but it would be strange eat a piece of roast beef and call it a "sandwich" simply because you bought it in a sandwich shop.
I understand your point about US usage of words being different. But I think you miss a lot of the Japanese food culture by confusing the terms. There is a lot of sushi that doesn't contain sashimi. In Japan, eating in a sushi restaurant is one of the easiest ways to accommodate vegetarians since there is a large variety of vegetarian sushi. On the other hand, sushi is not actually a very important part of Japanese cuisine. Sashimi is *far* more important. I couldn't imagine eating a high class meal without having sashimi. By understanding the importance of the different kinds of food, I think you will gain a better appreciation for what is one of the world's great cuisines.
You're app really isn't that good. Piracy really isn't as big as you'd like to think it is.
If you re-read my post I think you will find that you missed a lot in your first reading. I implied that the only reason for any success at all in the company was the piracy. Without the piracy, we had *no* customers. In our case piracy == good. Not that management could understand this...
The nature of the app made it easy for us to determine the level of piracy. If you have 10K users and 1K customers, 9K aren't paying. It's not difficult math. Since the users generally had to use facilities on our servers we could easily tell what was going on.
Just to make things clear, my last statement was sarcastic. Perhaps it isn't as obvious to others as it is to me, but our customers *didn't have any money*. This is why we failed. Not piracy. Piracy was helping. Some of those pirates had money and were willing to buy the app eventually. Moronic sales people trying to sell software to fly-by-night service companies with no money was a less successful tactic.
the developer is grossly over-estimating the value of their software, thinking "If my software isn't great, then why would anyone pirate it?"
I once worked for a small company with a semi-popular application. Sales were almost all of the form of pay pal purchases off the website. It wasn't a lot of money, but it was enough to pay one developer. But piracy was a huge problem. It was quite obvious that more than 90% of the copies running were pirated.
The company changed directions and started bundling the application for free with online services. The service provider would pay for the application and the customers would get the software for use only with the service. But the company was worried about piracy, so they asked me to write DRM that tied the application to the service. They would continue to sell an untied version off the website, but with "call home" DRM (it's an internet app, so it's not quite as draconian as it sounds). I very reluctantly agreed (i.e., I had to decide whether it was worth quitting over -- if I had to do it again, I'd quit).
The end result was that all piracy stopped. In fact, all usage stopped. Instead of selling 2 or 3 copies a day off the website, not one copy of the DRM version was ever sold. And due to very poor choices of service provider partners, the company received no revenue at all. Within a year the company had folded.
The thing is, the new version was head and shoulders better than then non-DRMed version. And the DRM was truly unobtrusive (think DRM in WoW). Paying customers wouldn't even know it existed. But sales are generated by popularity, not quality. Piracy, like it or not generates popularity. The company was very small and had no means of effective advertising. By cutting off the pirates, they shut off their only revenue source.
What always kills me about this story is this: The app we were making was *perfect* for an open software model. Ask the service providers to each spend a small amount of money to cover development and give them the app for free. Give them branding in the app to thank them for their help. But the "sales" people were always quick to point out that the service providers they found had no money and couldn't afford to pay us up front. How on earth did we fail?:-P
Under v2 the remedy is asking for forgiveness. You can't distribute the code further unless the copyright holder forgives you. Since this can be very difficult in practice, it's a serious weakness of v2. In v3 the situation is improved. Since I think this code was under v2, hopefully it had the "or later version" clause still intact.
Slashdot Mirror
The cost of living is highly dependent upon the standard of living. Those with a lower standard of living spend less money and it filters down through the whole system. So maybe you can buy a meal for $1 rather than $5, but everyone who lives there doesn't have running water. If you gave every body running water, the cost of living would go up. If you gave everyone the luxuries that Americans enjoy, it would cost as least as much as in the US.
You can't compare cost of living without comparing standard of living for the average person.
Sometimes I think people from "1st world" countries can't really understand what it is like to live without the opulence they are used to. Even people making minimum wage mostly have running water (hot and cold!), heat in their apartments (many even have AC!), sufficient clothes, and enough food so that they can actually have a choice whether or not to be obese. Most even have a few ridiculous luxury items like refrigerators, TVs, washing machines and cars (even if they aren't new).
Look at the people working in a factory in the US. Most of them are fat, right? Look at people working in a factory in China. ALL of them are thin. Trust me, food is the last "luxury" that you give up. This means that Chinese factory workers are living at a standard of living FAR below what most Americans would deem acceptable -- regardless of the "cost of living".
But the ISO 9001 standards aren't fixed. Basically you document what you are going to do, show that you've trained your staff to follow the process and show that the staff are following that process. You can easily do 9001 document control standards with a pen and a filing cabinet. Yes, there are some specific requirements: you must define a way to show that the currently accessible document is the most current one, etc. But 9001 doesn't require you do it any specific way.
In fact, if you simply buy a piece of software and say, "The software enforces the process" a good auditor (hah!) will fail you. The whole point of 9001 is to document a process, train your staff to follow it, and show that you are following it. You can buy a canned process, train your staff in that process, have tools to help you, show that your are following that process. You will pass 9001. But you will have a fucked up process because it almost certainly won't follow your company's natural workflow.
I suspect this is why the parent suggests that maybe looking for a tool rather than working on the process is a bad idea.
* About the "hah!" comment: I don't believe there exist good 9001 auditors. Or rather, if they exist, they don't work much. It is in a company's best interest to hire incompetent auditors. That way they pass the audit. I say that having done the job myself once a long time ago :-P
Simplicity is a bad word in this context, as you point out. There are two concepts that it points to which are always getting confused.
Ease of learning: Something that is easy to learn lacks conceptual complexity. It is easy to understand quickly and it is easy to remember after being exposed to it only a few times. The downside to ease of learning is that you usually can't do things that are conceptually complex.
Ease of use: Something that is easy to use lacks operational complexity. It is easy, fast and convenient to do what you want to do, no matter how complex. The downside to ease of use is that the ability to do complex things quickly usually requires an interface that is difficult to learn.
You can optimize for either of these kinds of simplicity (ease). Your interface can be unnecessarily complex in either or both categories. Good software chooses the least complex solution, while still optimizing for the type of simplicity that is required.
It is quite common in the financial world to sell an asset early for a smaller sum rather than wait for its full value to appreciate. There are several benefits to this. The first is that you get the money now. You may need the money to pay for things like rent and food. A million dollars ten years from now does me no good if I starve to death today. The second (and more important) is that you can offload risk to another person. Your song/book/software *might* be worth millions or it might be worth nothing. Sometimes it is better to opt for the security of a real paycheck rather than hope you will strike it rich sometime in the future.
As an author of software I have never regretted having the option to transfer my work to others in exchange for money. Although I made much more money for others than I made for myself, I don't think I was financially taken advantage of. The security of the paycheck was well worth it. These days I wouldn't transfer my copyright simply for money, but that's more an issue of control than anything else. I was never happy with *how* my work was used and how the customer was treated. By retaining the copyright I have more control. But I also don't make any money doing it ;-)
In language courses it is quite common to "teach to a test". The way I've seen it, they give the students huge, impossibly difficult
passages to read. Then they have a series of very difficult questions with multiple choice answers. Then the teachers teach
the students how to match the questions to the passages and deduce the answer -- all without understanding either
the passages or the questions. These students can pass extremely difficult standardized tests (which are all of this
format, because marking essay questions takes much, much too long and is considered too subjective). But even though
they can pass the exam, they usually can't speak the language at all.
A university prof *can* pretty much fire their students. They do so by giving them a failing grade. Enough failing grades and the student will be suspended for a year (and probably won't come back again). I think this is appropriate. A university student should be there to learn and the professor is simply a resource. A prof can be good at teaching, but the primary motivation needs to come from the student, not the professor.
In high school and lower, I believe things should be very different. A teacher's role is *not only* to present the material, but also to teach the students how to succeed. High school material in the west is ridiculously simple. The average person can learn it relatively easily. Those who can not learn suffer because they either don't know how to succeed, or don't want to succeed. Some people's lives are so traumatic that any thought of success escapes them completely.
If I were to teach only to my students who meet me half way, I'd have virtually nothing to do. I'd throw them new material and simply say, "Here, go learn this". And they would do it. In fact a lot of teachers do just this. 20 percent of the class is happy as clams. 70 percent sits in stunned silence and 10 percent go ape-shit insane. These last 10 percent are labelled "trouble makers" and said teachers do their best to get them run out of the school. This is a crappy way to teach.
While I am hardly an experienced teacher (I still pretty much suck) I can try a different approach. The students who meet me half way will learn the material no matter how good I am, so instead I try to get them to focus on their areas of weakness, rather than their strengths. Quite a few of them hate high school, so it's better to help them with social skills and improving their happiness. For the stunned, silent students I try to show them a method where they can easily succeed at academics. Success breeds success, so I try to catch them on a good day and get them to try. For the last 10%, I try to give them hope. I hold the door open as long as I can and encourage them to come through. Then I wait for them.
My classes work best when there is something for everybody. Disruptions occur when people get bored/lost/abandoned. The top students get an environment where they can study when the bottom students are engaged and cooperative. The bottom students get opportunities to succeed when the top students haven't moved completely out of their reach. It's a delicate balancing act.
The problem with frameworks is that they dictate design decisions. This can save you a lot of time up front because you don't have to rough in your design. You save a lot of coding effort. But if the project runs for a long time, your design will almost certainly move away from the original design. With a framework, you have 2 choices: write big ugly hacks to work around it, or abandon the framework. Since the second option is very time consuming everyone picks the first one. This results in code that slowly gets cruftier and cruftier. Eventually you lose all the time you gained up front and have a crappy code base to boot.
If you write your own, you will probably be reinventing a lot of wheels as you start. But you can easily refactor the design as you go, keeping your code base clean.
Having said all that, the number of teams that actually refactor their design as the go is vanishingly small. Most end up with crap no matter what they do. So, one might say that frameworks are generally useful. I often wonder if extremely minimal frameworks would be more helpful. The would contain only enough to get you over the beginning hump, but allow you to easily modify it as you go.
Personally, I have very few real problems with the legalization of marijuana except for one. The preferred method of ingestion is smoking and smoke is very rarely contained. *I* don't want to smoke marijuana whether directly or through second hand smoke. Even if only legal in one's own home, I have enough problem with people smoking cigarettes on their porch/balcony and having it waft through my bedroom window. As a recreational drug, someone's enjoyment of it shouldn't result in me having to smell it. As stupid as it is, the current illegal status of marijuana makes conversations like, "Would you please not smoke a joint right under my bedroom window" much easier than its tobacco oriented counterpart.
If it stops others from implementing this abomination, I'm all for it. As embarrassed as I am to admit that I use FB I have to say that the News Feed is horrible. I guess they were trying to find a way to show me what I'm interested in without showing me a whole bunch of garbage. They failed utterly. News Feed has some random kind of order that I can't fathom. It mainly shows me things I've already seen without showing me new stuff. And it seems I can't permanently turn it off.
At first I thought it was almost impossible. But then I started to think about a few AI vision algorithms and realized that actually the technology to do this has been around for a long time. But I will say that the application is innovative (at least for me). I wouldn't have thought about doing it at all.
I'm curious. Who do you get for support for Microsoft products. Does Microsoft offer support? And by support I mean, if there is a bug in Word corrupting your mission critical documents, will they promise to fix it? And will they give you a projected time for completion on the work. And will they give you periodic updates? And will they send you a patched version as soon as it is fixed? How much does that kind of support cost? Are you sure it's really cheaper than an open source project?
And what happens when Microsoft "End-Of-Life"s a product? Can you get support from a third party? Can you develop internal resources to provide support and add small features? Or do you have to simply buy whatever Microsoft replacing it with, regardless of whether or not it fits your needs?
And when you say that finding people able to do internal support (I assume first level support, since you can't really do anything else with proprietary software) is easier and cheaper with more popular software, isn't this simply a training issue? Do you really have such a high turnover rate in your company that most of them were trained in using software at their previous job? Or are most of them trained at your company, meaning that it doesn't matter if it's the most popular software or not -- It just matters that you can find initial training at a reasonable cost?
Certainly I think it's a good idea to get support for software you buy. However, I have never worked at a proprietary company that offered anything resembling what I think of as support. "Support" in the industry means get the off the phone as quickly as possible because every minute on the phone eats your entire profit. Sure we did special one-off deals for customers who bought 10,000 copies of our software, but we gave them a bloody hard time of it. If they didn't threaten to not upgrade to the next version, they wouldn't get anything at all. We might fix their bug in the next service pack, or maybe not, at the whim of the program manager.
Real support, meaning having someone who is contractually obliged to help you when your software doesn't work for you only seems to be available for custom built software. And if you aren't getting source with your custom built software, you're getting ripped off.
Or at least that's been my experience. It would be interesting to see how your experience differs.
The problem with measuring the effectiveness of programming techniques is that it is very difficult. It is quite valid to say that there are few studies to back up the effectiveness of various "agile" techniques. But I will point out that this is true of every programming technique.
The problem with measuring this is that it is impossible to get a baseline. There is a huge difference in productivity based simply on individual talent. This has been shown. So you will need thousands of programmers to test any theory. Problems are also extremely variable, so it is difficult to measure productivity across different problems. You would need to solve hundreds of non-trivial problems to test your theories. Finally, objective code quality is an unknown. Existing metrics are well known to be bad at estimating real quality. Solving any one of these measurement problems would be enough to get you a PhD.
If someone could find a good way to test different techniques and provide statistically significant results, they would be rich beyond the dreams of avarice. You use a variety of different techniques, which I assume you feel are more effective (or at least as effective) as others. Check the literature. Do you have any proof other than your own (or other's) anecdotal experience to back up your opinions?
Unfortunately, with the current state of affairs, we are very vulnerable to methodology snake oil salesmen. Everybody wants the cheap cure-all. Every popular methodology has more than its fair share of such leeches. As soon as it becomes a buzz, somebody wants to make a buck off it. The truth is that there are a lot of individual techniques that are effective, but you are going to have to put effort in to evaluate them yourself. Try to keep an open mind and keep several hours a week available for training and exploring these possibilities. You won't be sorry.
This is a really good post. I wish I could moderate you up. Like some people, I've become less enamoured with the word "test" for unit tests. It implies that I am trying to find out if the functionality works. This is obviously part of my effort, but actually it has become less so for me over time. For me, unit tests are used for telling me when something has changed in the system that needs my attention. I liken it to a spider's web. I'm not trying to find all the corner cases or prove that it works in every case. I want bugs to have a high probability of hitting my web and informing me. When writing new code I also want to be informed when I make an assumption about existing code that is different from the original author. I think about my assumptions and try to write unit tests that verify the assumptions. This often fills out most of my requirements for a "spider's web" since when people start messing with code and break my assumptions, my tests will also break.
Finally, your point about documentation is extremely good. A large number of people, even if they are used to writing unit tests, don't understand unit testing as documentation. I've gone to the extreme of thinking about my tests as being literate programming written in the programming language rather than English. To this extent, I've embraced BDD and write stories with tests. For each story that I'm developing, I'll create unit tests that explain how each part of the interface is used. I then refactor my stories mercilessly over time to maintain a consistent narrative. However, I often feel like I want a "web" (as in TeX's literate programming tool) tool that will generate my narrative, but will still allow me to view the code as units (which is useful for debugging).
The problem is that "Agile" as a methodology means almost nothing. We value people over processes, etc, etc. It could be anything.
I've worked on a couple of very successful XP style projects. One was so successful that it surpassed my wildest expectations. We had good people on the project, but it wasn't much different than other teams I've worked on before. The biggest difference was an interest in the XP practices and a consistent approach to applying them. The more we did it, the more we learned, and the more successful we became. I can't really explain it well, but the more code we wrote, the rate at which we could implement functionality increased (exactly the opposite from other projects I'd been on).
But it's this not being able to explain our success that is the problem. I now know what a lot of people mean when they talk about hyper-productivity in "agile" projects. And after that wildly successful project I would look on in despair at other projects. Management would suggest that this project was successful too and I would have to disagree. I could point to places in the code where cruft was developing. "All code has cruft", they would say. But cruft slows you down. It makes you have to think hard about what you are doing. It makes you make difficult decisions about what you should be doing. Truly agile projects can't afford cruft. Think about how easy it is to write new code compared to writing code in an old system. Well, truly agile code is *easier* to code in than new code. And the more you write, the easier it becomes. You get more functionality, it's better organized, it's easier to read, it gets closer and closer to the real problem domain. And it even tells you (through "tests") when you use it improperly.
This kind of code comes from the dedication of the developers, I think. The "agility" doesn't come from avoiding overhead. It comes from constantly making things easier and easier. It comes from being sensitive and saying, "That bugs me" and improving it -- every single time. It comes from understanding the separation between the business side where the 80/20 rule applies and the technical side where the 80/20 rule means you're going into technical debt everyday.
I have no doubt that there are people who experience the "agility" that I experienced using a variety of different methods. XP isn't what made me "agile". It was more of a bootstrapping process that let me start understanding what was important and what wasn't. I suspect there are people who are more talented than me who can see that without being shown. But from experience they are very rare indeed. And unfortunately the vast majority of people believe that "Agile" means exactly the opposite of the discipline that is required to achieve it.
OO is a very important project which has done a lot to show people that open source software is viable for desktop environments. But, and I say this as someone who uses oowriter every single day, it should be replaced with something better. There isn't a single program I use that causes me as much grief as oowriter. I'm working as a teacher in Japan right now and making handouts every day for my students -- actually, at this point I think it might be better to say I'm writing a textbook. I use a huge amount of clip art and I'm switching between Japanese and English a lot, so possibly my case isn't typical. But my documents get corrupted weekly. Sometimes the pictures delete themselves. Sometimes the fonts decide to change themselves randomly. Sometimes the document gets so bad that the cursor randomly jumps around the screen. When I am making my exams (which are very heavy with pictures) the scrolling the document is so slow that it takes 10 seconds to get to the end of the page.
I have slowly been writing latex macros so that I can finally ditch OO (it's quite difficult given the number of unique formatting I have to do, from word searches to crossword puzzles to bingo boards -- all with clip art liberally sprinkled on the page). When I'm done I won't be the least bit sorry to see the back of OO. But not everyone can sit down and write custom latex macros to format their stuff. I'm kind of hoping that a potential lack of OO funding will remind people of other solutions like KOffice or Abiword (which aren't quite there yet for my applications, but noticeably less crufty).
What confuses me is this: isn't having a distributor dictate the price of an item to a retailer called "price-fixing"? Isn't is illegal in the US? If I understand correctly, Macmillan and many authors are upset that Amazon want to sell at a reduced retail price while still paying the *same* wholesale price. Shouldn't that be allowed in a free market economy (as long as they aren't selling below cost in order to force out smaller players)?
So why did Amazon have to capitulate? Clearly they have to buy the books at whatever rate the publisher wants. That's fair enough. But I can't understand why they can't set whatever retail price they want.
The trick is that "far-left" and "far-right" are simply inventions to keep people arguing about trivial matters. So occupied, the masses don't realize what is actually happening in the circles of power. It amuses me that American media is always so polarized. The even hire people to take up "far-right" and "far-left" stances and argue on camera. Given the vitriol engendered in their arguments, viewers mistakenly believe that the topics are important. This allows policy makers to carry on with their agenda without interference from the unwashed masses.
Not sure if you're trolling or not. But just to clear up a common misconception, the vast, vast, vast majority of manga is not pornographic at all.
Pornographic manga is definitely available in Japan, but not all of that depicts children. Pornographic manga is available in most book stores and as far as I can tell most of it depicts adults. There is definitely a sub-genre that depicts high-schoolers, but it is not the most numerous by any stretch of the imagination. As for manga depicting pre-pubescent children, I've never seen any in the shops. Probably you'd have to go to a specialty store of some kind. Where I live, I wouldn't have any idea where to start looking. Nor would anybody else I know around here.
Graphic novels are a ligitimate avenue of storytelling that is very popular in Japan. Equating them with child-porn is really way off the mark.
Having said that, my friend's niece is really into Inuyasha, so I mailed her the Japanese version of the first volume. I didn't realize at the time that there is a single topless picture of the main character (a 14 year old girl) in this volume. So it seems I am unwittingly guilty of distributing child porn into the US, to a child no less... :-P
The thing is the GPL isn't the "golden chalice" even for the FSF. That's why they have the LGPL. And nobody (that I've ever heard of, anyway) is going to criticize anybody for choosing another free license (like BSD) either. Choosing the correct license is a very important thing and every developer should think very carefully about it before they release. I can't tell you the number of times I've heard developers complain about being "ripped off" because somebody used their code in a "commercial product" without their consent -- only to find out that they had a BSD license. Or that they complain about being "ripped off" because someone charged money for their application without their consent -- only to find out that they had a GPL license.
People need to think about what they want to accomplish with their license. Sometimes something like BSD is the best. The advantages are wide adoptability. People can join your project easily. But someone may just stick your code in their own product. You'll be competing against yourself, but at a disadvantage since they can use your code and you can't use theirs. For a lot of stuff you don't care and BSD is great.
Maybe you care about end users being able to use the latest version of your code, but you don't care about unfair competition. In this case the LGPL is a great license. Anybody can use the code any way they want, but your users can fix bugs in your code or add new functionality, etc.
Maybe you care about making sure nobody can use your code to leverage an unfair advantage against others. Everyone who adopts the code in their program must agree to a common set of principles. This way nobody is at a disadvantage. The GPL is great for that. But remember that the more restrictive your licensing is, the less potential users you will have. And there is no question that the GPL is more restrictive than the BSD license. However, for the reasons above (and many others) a very large number of people think it strikes a very good balance.
Personally, I don't like licenses that are more restrictive than GPL. As a user as well as a programmer "free" (as in software) is extremely important to me. It's worth more than money to me. I regularly fix bugs and add features to code I use. And I value the ability to ask my friends to help me out when I can't fix it myself. When I have had to use proprietary software (both as a user and programmer) I have almost always been very frustrated with the lack of ability to fix my own problems. I've decided never to write software that is more restrictive than GPL and I wish others would do so as well.
I'm going to have to disagree with this.
Software patents were a problem then and are still a problem now. Patents have always been a trade off. At one time everyone making inventions hid their work through secrecy and obfuscation. This is clearly their right and in order to protect the upfront investment in research and development it was necessary. Otherwise someone could use the information that other people had developed in order to create a product without the upfront investment. They could then undercut the initial inventor.
The result of secrecy and obfuscation was that society couldn't build on top of new ideas. Progress could stall because only a few people knew how something worked. So a limited monopoly was granted to inventors in exchange for full explanations of their inventions. It was hoped that this monopoly would allow others to build on previous inventions and accelerate progress.
This is fine when we are talking about real physical machines. We aren't giving monopolies on ideas, rather their expression in physical form. In the world of physics, only certain things work for a given problem. For example with velcro the hooks have to be at a certain angle and the loops have to be at a certain density. Nobody can patent the idea of a hook or a loop. But a specific physical arrangement of hooks and loops with a specific application is patentable.
The problem with software is that it isn't constrained by physics. For any given problem there are many expressions that can work. Software *isn't real*. If my hooks and loops don't match up I can change the laws of physics to make them match. The work in developing software is *not* trying to discover the angle with which a hook must be made, but rather the sheer volume of describing the hook.
Because people misunderstand the purpose of a patent, they believe that patents exist to protect the upfront investment of development. In this case, if it takes a year worth of work to type in the description of my hook, that hook must be worthy of protection. It is, after all, a considerable upfront cost in my act of invention. But the *specific description* of the hook (i.e., the source code) is not what they want to patent. After all, they already obfuscate it and have a copyright for it. It is amply protected. What they want to patent is the idea of a hook for a given application. *All* descriptions of hooks for that application are now forbidden.
Now we could argue that some techniques are difficult to develop. This is true. But on a computer, all techniques are mathematical algorithms. These are not, and never were patentable. If we accept the argument that a computer program is a "software machine", then the patentable part must be the description of the algorithm in the computer. But this is already obfuscated, secret and protected by copyright. They wish a higher level protection on the concept itself. This is a problem because it has never been patentable (if you wish a reason, I direct you to read the original arguments given when instating the patent system).
Not only are software patents a problem, their very nature is what is causing "bad patents" and "money through litigation" schemes. Any software patent must, by necessity, by overly broad and provide an opportunity for abuse. Not only should software patents be disallowed, but also "hardware" patents that can be fully implemented in software. To do otherwise is to fly fully in the face of the original intent of patents.
Computerized health care systems are not designed for the benefit of hospitals. They are designed for the benefit of entrepreneurs.
Health care is a multi-bazillion dollar industry where information is managed via bearskins and stone knives. Development of an integrated computerized health care system will net the intelligent investor more money than even Microsoft can dream about.
This is the message that people I will call "serial entrepreneurs" pitch. Their intent is not to build such a system (that would be nigh on impossible given the absolute chaos of incompatible processes that currently exist in hospitals). They simply want to build a system that looks close enough that stupid investors will throw millions of dollars at it. The potential payoff is so big (seemingly) that people will keep throwing money at it even after said entrepreneurs have razed and burned a stack of companies.
Of course, eventually there *will* be a company that succeeds (mostly by accident). That company will run suspiciously like SAP where there will be a very complex set of computer programs designed to support an even more complex set of processes. These processes in turn will have nothing to do with the underlying business of providing health care. However senior management will be ecstatic that they finally have a unifying computer based process, and the only people who fully realize its true futility will be the people doing the work. They, of course, will be ignored.
In Japan sashimi is always served in sushi restaurants. A person may say, "Let's go eat sushi" and then at the restaurant end up eating only sashimi. But at a banquet sushi is almost never served. Sashimi on the other hand is virtually always served. A person would never say, "I went to a banquet and ate sushi" meaning that they ate sashimi.
Historically, sushi is a snack food. It's kind of an all-in-one meal since the rice is included in every bite. In a way you can think of it as a sandwich. In western culture, bread was once seen as the most important part of a meal. With a sandwich, you eat the bread with the meal. But you can also eat bread separately with the meal. You can eat a roast beef sandwich, but it would be strange eat a piece of roast beef and call it a "sandwich" simply because you bought it in a sandwich shop.
I understand your point about US usage of words being different. But I think you miss a lot of the Japanese food culture by confusing the terms. There is a lot of sushi that doesn't contain sashimi. In Japan, eating in a sushi restaurant is one of the easiest ways to accommodate vegetarians since there is a large variety of vegetarian sushi. On the other hand, sushi is not actually a very important part of Japanese cuisine. Sashimi is *far* more important. I couldn't imagine eating a high class meal without having sashimi. By understanding the importance of the different kinds of food, I think you will gain a better appreciation for what is one of the world's great cuisines.
But, as always, YMMV.
How on earth did we fail?
You're app really isn't that good. Piracy really isn't as big as you'd like to think it is.
If you re-read my post I think you will find that you missed a lot in your first reading. I implied that the only reason for any success at all in the company was the piracy. Without the piracy, we had *no* customers. In our case piracy == good. Not that management could understand this...
The nature of the app made it easy for us to determine the level of piracy. If you have 10K users and 1K customers, 9K aren't paying. It's not difficult math. Since the users generally had to use facilities on our servers we could easily tell what was going on.
Just to make things clear, my last statement was sarcastic. Perhaps it isn't as obvious to others as it is to me, but our customers *didn't have any money*. This is why we failed. Not piracy. Piracy was helping. Some of those pirates had money and were willing to buy the app eventually. Moronic sales people trying to sell software to fly-by-night service companies with no money was a less successful tactic.
the developer is grossly over-estimating the value of their software, thinking "If my software isn't great, then why would anyone pirate it?"
I once worked for a small company with a semi-popular application. Sales were almost all of the form of pay pal purchases off the website. It wasn't a lot of money, but it was enough to pay one developer. But piracy was a huge problem. It was quite obvious that more than 90% of the copies running were pirated.
The company changed directions and started bundling the application for free with online services. The service provider would pay for the application and the customers would get the software for use only with the service. But the company was worried about piracy, so they asked me to write DRM that tied the application to the service. They would continue to sell an untied version off the website, but with "call home" DRM (it's an internet app, so it's not quite as draconian as it sounds). I very reluctantly agreed (i.e., I had to decide whether it was worth quitting over -- if I had to do it again, I'd quit).
The end result was that all piracy stopped. In fact, all usage stopped. Instead of selling 2 or 3 copies a day off the website, not one copy of the DRM version was ever sold. And due to very poor choices of service provider partners, the company received no revenue at all. Within a year the company had folded.
The thing is, the new version was head and shoulders better than then non-DRMed version. And the DRM was truly unobtrusive (think DRM in WoW). Paying customers wouldn't even know it existed. But sales are generated by popularity, not quality. Piracy, like it or not generates popularity. The company was very small and had no means of effective advertising. By cutting off the pirates, they shut off their only revenue source.
What always kills me about this story is this: The app we were making was *perfect* for an open software model. Ask the service providers to each spend a small amount of money to cover development and give them the app for free. Give them branding in the app to thank them for their help. But the "sales" people were always quick to point out that the service providers they found had no money and couldn't afford to pay us up front. How on earth did we fail? :-P
Under v2 the remedy is asking for forgiveness. You can't distribute the code further unless the copyright holder forgives you. Since this can be very difficult in practice, it's a serious weakness of v2. In v3 the situation is improved. Since I think this code was under v2, hopefully it had the "or later version" clause still intact.