Richard Monson-Haefel's Blog

Community Archives

9 of Clubs Seeks a new Deck of Cards

Recently I had the honor of being named one of the 53 most influential people in the Java industry by The Middleware Company. My card was the 9 of Clubs – I have no idea how to interpret that distinction. Obviously, it’s a nice complement especially considering that the votes came from developers who subscribe to TheServerSide.com mailing list – a resource I consult regularly even if the threads are frequently hijacked.

You would think that a guy in this deck of cards is probably making gross amounts of money and living a leisurely life. I can't speak for the other people on the list, but that doesn't describe my life at all. I work really freaking hard – as hard as anyone reading this blog – and I don't own a yacht or drive a Lamborghini. I'm not poor by any stretch of the imagination, but I'm not going to make the Forbs list anytime soon.

The truth is being an independent is hard work. I've been at it now for about five years and its never been a cake walk – ok occasionally it's been easy, but most of the time its not. For the most part I'm busting my butt trying to convince companies that I'm worth what I'm worth even if John and Jane Doe charge a faction of the price. The truth is, I'm usually over qualified for most consulting gigs so the spectrum of opportunities available to me is actually less than the average developer.

I heard once that winning an Oscar in Hollywood is a double edge sword. Actors who win are recognized for the quality of their work, but subsequently find it hard to find work. I even heard it descried as the Oscar "Death Knell": Its great to win, but its better to get nominated. This is probably a bit of hyperbola and I don't mean to compare my meager success to winning an Oscar, but the truth is: Success is measured in many ways and peer recognition – while wonderful – doesn't always translate into big bucks and loads of free time.

After more than five years of going-it-alone, I finally asked for help. This Monday I decided to try my luck for the first time with the grape vine. Although I have frequently helped others find work, I've rarely asked for help myself. Why? Well I guess I felt that I should be able to find my own work. Also it’s a matter of pride. I don’t like to ask for help. I don't want my peers to know that its hard for me to find work that fits my skills and pays well – everyone seems to assume that if your well known you automatically make tones of money. Its not always true.

I've been very involved in the Java industry. Two months after I started learning Java I started the Wisconsin Java User's group – that was back in the spring of 1996. Since than I've volunteered for all sorts of things from open source projects to JSRs and I'm proud of what I've accomplished. The culmination of all this altruism was being voted into the JCP Executive Committee last fall – an honor I've take very seriously.

I've done good things for our industry, but I feel its time to step back and let others have the glory. I have a family now. My boy, Henry is about 2 1/2, and my daughter, Olivia, is just 9 months. I need to look inward toward my family and put them first. That means I need to find a stable job with some longevity and hopefully something with a lot less travel. I think I was honored with the 9 of clubs because I've donated so much of my time to the Java community – people will probably laugh at that, but I can't think of any other reason. Working on expert groups, open source, and the JCP consume enormous amounts of time, but pays nothing, zip, zilch. That's ok, I knew that going into these endeavors and its expected that I should be able to leverage my contacts and name recognition into a living. I have done that to some extent, but it hasn't been easy. You still have to find work that fits your credentials and sell yourself at rates that are affordable – these are usually contradictory objectives after a certain point.

OK, so why this blog? Well, I'm hoping that someone will read it and say "Hey, I got just the job for this guy! What's his e-mail address?" (btw it is Richard@Monson-Haefel.com). Head hunters and other professional placement guys should not bother to contact me - you guys are evil.

There is another reason: On occasion I've had people ask me how they can manage their career to become more successful – to be more like me. This always makes me wince. I've been fortunate – no doubt about it – but I wouldn't recommend my life style to anyone. It’s a lot of work with very little pay. As I said, peer recognition is great – its probably the best recognition you can have – but making a living is not a bad thing either. I'm honored to be counted in that deck of cards with the likes of James Gosling, Rod Johnson, Gavin King and others – but its time to join a new deck – one that gives me more time with my family and actually pays a salary.

JSR-241: Groovy – A New Standard Programming Language for the Java Platform

Until now the Java programming language has reigned supreme as the standard programming language for the Java Platform. It has served us well for close to nine years, but it cannot be all things to all people. And it shouldn't. The Java Programming language, like C++ and C#, is a strongly and statically typed programming language. While this type of language, sometimes called a "conventional" language, is useful for solving many problems, it is not a panacea. Conventional programming languages are very exacting, meaning that you have to dot every 'i' and cross every 't' in order for the program to compile. This orthography of statically defining all the types may result in more predictable code, but it also tends to slow developers down.

An alternative to conventional programming languages are agile programming languages like Python, Ruby and Perl among others. These agile languages have long been called "scripting" languages, but that term is not, IMO, sufficient. Many in IT perceive scripting languages as layman languages that sacrifice technical sophistication for easy of use. This may be true of some scripting languages, but it's certainly not the case with Python, Ruby or Perl. These are dynamic and powerful programming languages that happen to use less syntax to accomplish more.

To be perfectly honest, although I'm listed on the JSR as a co-spec lead, I'm a Johnny-come-lately to the Groovy bandwagon. Groovy already has a grass roots following and all the credit for the development of Groovy goes James Strachan and other contributors to the Groovy open source project. I'm not a language designer, but I understand the power that languages like Python and Ruby offer developers and I believe it is time for the Java Platform to include an agile programming language. It's this personal conviction that led me to initiate and co-develop JSR-241 with James Strachan and Gier Magnusson of Apache. My role as a specification lead is to manage the progression of this JSR through the JCP and author the Groovy Language Specification – two tasks that can be terribly distracting to those doing the really hard work of developing the JSR itself.

Groovy represents the beginning of a new era in the Java platform, one in which the Java community embraces language diversification and harnesses the full potential of the Java platform. It’s the recognition that the Java is more than a programming language; it’s a robust platform upon which multiple languages can operate and co-exist. To me this has always been the unrealized promise of the Java Platform.

The Java programming language is, simply put, a convenient abstraction for the real language of the Java platform: byte code. As a user-friendly abstraction for byte code the Java programming language is powerful, but it's not omnipotent. There are circumstances in which a different language, an agile programming language, is more expressive and productive.

So why Groovy? Why not Jython or JRuby? Why not one of the dozens of other programming languages that are designed to run on the Java Virtual Machine? It's my opinion, and I believe the opinion of those who support this JSR, that Groovy is the best choice because it was built from the ground up for the Java Platform and uses syntax that is familiar to Java developers, while leveraging some of best features that Python, Ruby and Smalltalk have to offer. Jython and JRuby are excellent examples of how existing languages can be ported to the Java platform, but they are, after all, ports. They use syntax that is not designed with Java developers in mind and they are founded on a completely different set of code libraries. Groovy is designed for Java developers and its foundation is the standard APIs of the Java Platform.

The New York Times on Amazon.com Fraud

There is, in my opinion, only one solution to Amazon.com's fraud-ridden book review system: Only customers who purchased the book from Amazon.com should be able to post a review on that book. Reviewers should be allowed anonymity, as long as Amazon.com keeps track of the reviewer's real identity. Amazon.com should not allow any Tom, Dick or Harry with a Yahoo! Or HotMail Email address to post reviews on any books they want – that's the system they have now and it has resulted in a review process that cannot be trusted. If you buy the book from Amazon.com, then you can review it.

13 improvements for EJB

What struck me, after counting and grouping relevant posts, was that the developer community desperately desires a simpler programming model for EJB.

In particular developers appear to be most interested in the following:

1. Ditch CMP or make it simpler like Hibernate or JDO
2. Use a POJO programming model
3. Add support for Interceptors/filters/AOP.
4. Eliminate/Consolidate the component interfaces (remote, local and endpoint).
5. Make deployment descriptors more like XDoclet
6. Instance-level authentication/entitlement.
7. Replace the JNDI ENC with Dependency Injection (a.k.a. IoC).
8. Add a Mutable Application Level Context
9. Support development and testing outside the container system.
10. Define cluster-wide singletons for EJB.
11. Clearly specify and standardize class loading requirements.
12. Standardize the deployment directory structure for EJBs.
13. Support Inheritance.

Some of the items can be grouped together to give more weight to a particular approach. For example, item 1, 2, 4, 7, 9 and 13 all seem to point at a CMP programming model that is more like Hibernate. Hibernate uses a POJO programming model with dependency injection (IoC) and is not dependent on client interfaces. In addition, Hibernate applications can be developed and tested without a container system. A tip of the hat to Galvin King and crew.

Other items were interesting but not surprising like asking for an XDoclet-like vendor-agnostic deployment processes. This is a big concern of mine since EJB isn't really portable in its current incarnation – you can't just drop an EJB JAR into most J2EE servers without adding some vendor specific deployment information. Actually this aligns nicely with the request that EJB define a standard directory structure for deployments similar to Web components.

The mutable application level context was a surprise for me. Standardization and specification of class loading behavior was not a surprise. Requests for instance-level authorization was also expected – it's something developers have been asking for since EJB 1.0.

I was delighted to see so many posts on this subject. Clearly people feel there is much to be done. I was less excited to see the thread wander off into Spring vs. JBoss vs. Mike Spille territory – but I found those posts interesting too.

Obviously, there are better mechanisms for measuring public opinion than a blog. Perhaps someone will take on the task of organizing a more accurate pole, but for me the information and posts were very informative. I read every one of them. I greatly appreciate the time and effort so many put into responding. Thank you.

I'm sharing these findings with the JSR 220 (EJB 3.0) Expert Group and expect your comments will generate a lot of discussion and a great deal of solid action by the group members. Keep an eye on JSR 220, eventually it will make it into public review at which time you'll have something solid to review and comment on. Your feedback is critical to the success of EJB.

You can make EJB better

What do you like or dislike about EJB? If it's broke, how should we fix it?

This is an excellent chance for you to make a real difference. All I ask is that you stick to the facts and your own experiences. Please try to avoid flames, zingers, and debates so that I can make the most of your feedback.

Open Source Developer: Will Work for Food!

UPDATED: January 23rd, 2004

I've received a lot of mail and seen a lot of postings about this blog entry. Some of it has been supportive and some of it has been …. Well, not. The one thing that is common to all but a few of the responses is that people have misunderstood my point. This is good evidence that I did a poor job of articulating it – something writers struggle to avoid. Anyway, I offer the following as a clarification.

Here is the point of the blog:

The majority of open source developers are not paid for their contributions. I'm not talking about high profile core contributors; I'm talking about all the other people who make open source a success. What pains me is that some of the few who make a living doing "professional open source" try to paint the picture that everyone is making money. That's not true, and its not why open source works.

Open source works because it gives developers freedom of choice and expression. Developers get to choose which projects they work on and therefore the direction of their own technical growth. Developers get to choose what to contribute and how much. It's about freedom of choice.

People give all kinds of reasons for doing open source that are simply variations of the freedom of choice theme. For example, developers feel a need to "give back" to their community. Well open source makes that possible because it gives you the freedom to contribute code, bug fixes and documentation. Another reason given, is that people get involved in open source to "build their resume", which is just another freedom of choice. Open source lets you build practical experience in just about any area of software you are interested in – ask your employer if you can start doing game development on their time and see what they say.

I have worked as a professional open source developer, and sometimes I've been paid for my work. Today, I'm not paid to work on open source but I continue to contribute as best I can because it gives me the freedom to work on those things I find interesting.

Open source does offer the potential to make money - No doubt about it - but that's not why open source is successful. It's simply a benefit of the freedoms open source offers us as individuals. It's not about ego; it's about choice. It's about fulfillment and creative expression. Money is great. I'm all for it, but its not why I work on open source. I could make a lot more money working for a vendor, but then I wouldn't be able to choose what and when and how I do my work.

The simile that I gave of a "fine artist" was meant to illustrate the motivation of the average open source developer. I have a few friends that are artists. Some are commercial artists and others are non-commercial artists, sometimes called "Fine artists". My commercial artist friend has never had a lot of choice in the medium he works in or the subject of his work or even the creative direction. He does what the customer wants, which is how most successful business work. My non-commercial artist friends, the "fine artists", work in any medium they please, on any subject, in any way they want. The motivations of the fine artist are intrinsically the same as those of the open source developer – freedom of choice and expression.

Paradoxically, freedom always comes at a cost. You must give something up, usually something tangible like money, lives, comfort, and such things to have freedom. Most open source developers do not make money doing open source work (contributing patches, bug reports, helping others on the mailing list, etc.), but they do benefit. They have freedom.

*************************************************************************************************
Oringinal Blog Entry: Janaury 22nd, 2004

I have a friend who works in commercial software and makes a pretty good living – actually a real good living. He finds the "whole open source thing" quite incomprehensible. Why on earth would you waste hours of your own time creating software without pay? My wife wonders the same thing.

The truth is: The difference between open source developers and commercial developers is the pretty much the same as the difference between a starving fine artist and a fat and happy commercial artist. The commercial artist, if she is any good, is probably paid a decent amount for creating logos, advertising, album covers and such things for someone else. A person who creates fine art, on the other hand, isn't likely to make more than a pittance even if they are lucky enough to get a show. While it's true that that some fine artists make it big, this is relatively rare when you look at the whole population. So why do people choose to create fine art, rather than commercial art? Freedom. Fine artists get to work when they want, create what they want, take credit for their work, and in the end enjoy the public scrutiny of their peers.

The same is true of open source developers. While a few make really good money selling consulting and training and other services, the vast majority of open source developers don't make anything. But they do have freedom. Open source developers can choose which projects they will work on and how and when they'll do the work. In the open source world no one will tell you what projects you must work on, or when you should work, or how much you should do. That's up to you. For the most part you are free to be as creative with your code as you like – if your code is good it will be adopted. If its sucks it won't.

So the price of freedom of expression for most, if not all, open source developers is … well poverty. Ok, that's a bit of an exaggeration since a lot of open source developers have a day job, but that's just as telling. To do open source, you have to have a day job. You can't expect open source to feed your family or even your cat for that matter. As I said there are exceptions, but most open source developers do it for the love of writing software. While commercial software developers do a great job of feeding their families, open source developers do a better job of feeding their minds. In the end, you have to ask yourself which is more important: The things you own or freedoms you have.

Groovy, Baby!

Groovy combines features of Python and Ruby (two popular scripting languages) into a Java friendly syntax. It makes working with object graphs (e.g. a bunch of business objects that have complex relationships) really easy – it's great for working with collections, XML and HTML. There is also support for regexp, SQL and scripting of Ant tasks.

Groovy saw its first release last December 2003, but its still very much a language with room to grow. If you are interested in getting in on the ground floor of what I believe will be an important new scripting language, than please visit the Groovy web site and see what you can do – testing code is always a big help. Personally, I hope to help with the documentation of this language.

The bottom line is that Groovy is not a replacement for Java – it’s a tool you can use to be more productive with Java. Groovy's not a silver bullet either. I can imagine lots of scenarios where I would prefer to work with the Java programming language, but its very useful in certain circumstances especially when organizing and filtering object graphs or text data – for example text files or XML or what have you.

IBM and BEA: Are they thumbing their noses at the JCP?

The Java Community Process (JCP) is designed to facilitate the creation of standard, vendor-agnostic Java technologies. This is my quick and dirty definition, the keys to which are the words "facilitate" and "vendor agnostic". The primary objective of the JCP is to provide a framework for defining Java standards. In most cases, an expert group develops the standards based on a set of objectives defined by the proposed JSR (Java Specification Request). In other words, usually the specification is grown from scratch under the auspicious of the JCP. This, however, is not a requirement. The actual specification can be grown from scratch (e.g. JSP, JSF, EJB, etc.), based on established non-JCP standards (e.g. CORBA, DOM, SAX, ext.), or an existing implementation or architecture as is the case here. It really doesn't matter very much as long as the JCP accepts the JSRs, approve their progression through community and public drafts, and endorses the final specifications. The bottom line is that the JCP is not supposed to stifle the development of specifications seeded outside of the process - to the contrary. If leading vendors want to hammer out the details before beginning a JSR, then so be it. Who cares how it got started?

Contrary to what my friend from Microsoft Land may say, the JCP is not doomed to obsolescence – not by a long shot. The truth is, IBM and BEA need the JCP. Neither of these companies could go it alone, outside the JCP. For example, before EJB/J2EE, both IBM and BEA marketed proprietary server-side component models. IBM's was called Component Broker and BEA's was called M3 (a.k.a. Ice Berg). Both vendors abandoned their proprietary architectures in favor of Enterprise JavaBeans. Why? Because their customers had more confidence in standards based solutions than proprietary ones. It’s the money that talks, and the money (customers) prefers standards to proprietary solutions. That hasn't changed and since IBM and BEA are not a standards organization, they will always need the JCP – or something like it - to manage the standards on which their products are built.

A little history illustrates the necessity of a standards organization like the JCP. In the mid to late 90's CORBA, not J2EE, was the leading application server standard for non-Microsoft vendors. The OMG defines the CORBA standards and initially vendors fell in line with those standards. But after Visigenic and IONA emerged as the market leaders (not unlike IBM and BEA today) they became more antagonistic toward the OMG. Now to be perfectly honest, I think the OMG was getting a little carried away, but that doesn't change the outcome. IONA and Visigenic thumbed their noses at the OMG to their own undoing. Where are Visigenic and IONA today? Are they still the major players? No, I'm afraid not. They've become minor players in the J2EE market. EJB and J2EE came along and everyone – vendors, customers, and developers – jumped the CORBA ship and went to J2EE. J2EE is the centerpiece of server-side products in Java Land because it’s a vendor agnostic standard that vendors respect and follow. IBM and BEA know this and are not eager to repeat the mistakes of their predecessors. They will continue to work with and conform to the requirements of the JCP. If they don't, J2EE will be lost and so will IBM's WebSphere and BEA's WebLogic.

The Rebel Alliance: Apache / ObjectWeb Join Forces

ObjectWeb, if you haven't heard of it, is an organization similar in purpose to the Apache Software Foundation (ASF). They have a fairly large offering of their own, but until recently they have predominantly used a LGPL license, which is simply incompatible with the Apache's BSD-style license. When Geronimo was announced back in August, some of the engineers from ObjectWeb approached us (I'm a Geronimo team member) about collaborating on some projects. Their JOnAS and JOTM development teams are also working toward J2EE Certification so they are creating a lot of the same components (EJB container, Transaction Monitor, Messaging, etc.) that the Geronimo folks are working on. The ObjectWeb engineers suggested that we collaborate on facilities common to both projects. The Geronimo team was very interested and agreed to meet with ObjectWeb at ApacheCon. That meeting took place last night.

The synergy, other than licensing, between ObjectWeb JOnAS/JOTM and Apache Geronimo appears to be excellent. Our development cultures are admittedly different but the differences actually strengthen our alliance rather than weaken it. The JOnAS/JOTM folks are, on average, older and more experienced in big-iron (mainframe kind-of stuff). Their depth of knowledge is really incredible – David Egolf of ObjectWeb kept Geronimo developers mesmerized for hours after the BOF talking about mainframe transaction processing. It was, for me at least, like finding my own Obi-Wan Kenobi. Given the chance I would have spoken to him all night.

While the depth of knowledge exhibited by the JOnAS/JOTM teams is extraordinary, the ObjectWeb folks tend to be slower out the gate than Geronimo. This is because they are more methodical. They are, in essence, the old men of the sea. The Geronimo team, on the other hand, is younger. These young-upstarts tend to develop solutions quickly and redesign often. But the output form the Geronimo folks is staggering. For example, the Gerionimo team is close to having an alpha release of the J2EE Geronimo platform four months after starting development. The technical expertise of the Geronimo folks is nothing to sneeze at either – almost everyone I've been working with has developed at least one successful open source container system before Geronimo.

So how will these teams work together? We will leverage each other's unique cultures and experience to co-develop common components for our J2EE container systems. The best, and first, example of this is JOTM. JOTM is ObjectWeb's transaction processing monitor. Transaction processing monitors are notoriously tricky critters to get right, and being able to plug in an existing and – according to Dain Sundstrom – excellent implementation like JOTM is a huge win for Geronimo. In addition, the JOTM people will go on to develop journaling and recovery, which is perhaps the most difficult and most critical aspects of a enterprise transaction manager – it's what makes transaction managers truly reliable. No open source project today offers a real journaling and recovery system. JOTM will be the first. Since the JOnAS/JOTM folks have more depth in this area, the Geronimo team is happy to endorse and support their development efforts. From this point forward, Geronimo and JoNAS will co-develop, maintain, and utilize JOTM for their transaction processing monitors. Of course, this would not have been possible if the JOnAS team had not agreed to change the license of JOTM from LGPL to BSD-style at the meeting last night. That was the last barrier to collaboration between the groups, and it turned out not to be a barrier at all.

For their part, ObjectWeb is thrilled to have the support of the Geronimo team and just as importantly, they are excited about the prospect that their software will be reused outside of ObjectWeb. This is open source after all; we believe in sharing software, exchanging ideas, and cross development. Geronimo will be contributing resources and unparalleled expertise in the Java platform – no one leverages byte code complication like the Geronimo team.

It's been an interesting turn of events. Before the BOF with ObjectWeb last night, the Geronimo folks worked together 16 hours a day at ApacheCon and were inseparable. As of today all that has changed. Now it’s the Geronoimo and ObjectWeb folks that are inseparable: The old men of the sea share their decades of hard-won big-iron wisdom; the young Geronimo upstarts share their passion, container development experience, and Java platform expertise. The feeling of camaraderie is sincere and an unadulterated. This is the start of a powerful alliance and the beginning of many new friendships.

The State of Geronimo

What does that mean? Well, it means that Geronimo, when it's ready, can be tested against Sun's Technology Compatibility Kit (TCK). An application server has to pass the tests in TCK in order to be called "J2EE Compliant". The fact that Sun has extended this license to Apache, is a huge vote of confidence in the Geronimo project. It says that Sun believes that Geronimo is a legitimate application server that may, provided it passes the TCK, be called "J2EE Compliant." Although, ObjectWeb (another open source organization) was given the TCK scholarship (something Geronimo still needs), Geronimo is the first open source project to receive the license. The license gives you permission to run tests against the TCK, but it normally costs a butt-load of money to label an application server as compliant – that licensing fee is one of the ways that Sun realizes income on J2EE. The scholarship, on the other hand, is designed to support non-profit organizations. It basically waves the costs that commercial vendors are required to pay in order to use the "J2EE Computable" branding.

But wait! That's not all … it was also announced that Geronimo will be using OpenEJB as it EJB container system. Actually, several of the Geronimo folks have been hard at work on a new OpenEJB branch that can be used by Geronimo and the established OpenEJB community. This is an item close to my heart, as I co-founded the OpenEJB project with David Blevins four years ago. It's been a blast working with the OpenEJB code base again. My hat is off to David and the rest of the OpenEJB community – the fact that the Geronimo folks chose to use OpenEJB, rather than develop their own EJB container system is a huge endorsement of that project.

There is more to this, specifically about Geronimo collaborating with ObjectWeb, but I'll cover that tomorrow …

Amazon.com reviews are a farce.

When a book is sold on Amazon.com anyone can post a review about it whether they read it or not. All you need to do is create an account on Yahoo or HotMail and then create a new Amazon.com account with that e-mail address. You can be a Fred Smith, Barney Rubble, or anyone you want - you can even impersonate someone. Amazon.com doesn't seem to care. It's a prefect set up for fraud, and for people with no scruples it represents a simple way to pump up their own ratings while knocking down their competitors.

More recently, I've become aware that some individuals have gone a step further by posting fake five-star reviews on their own books using the names of famous people in our industry. If you think that's stupid, let me assure it happens. In fact, I found one book that had at least one (probably three) reviews impersonating well known figures in our industry. How do I know they were fakes? I asked the people I suspected were being impersonated. I myself was impersonated on Amazon.com in a slightly different manner.

A couple months ago I discovered two book recommendation lists that were posted under the name "Richard Monson-Haefel" on Amazon.com's Listmania page. One was called "Great Books on Web Services" and the other was "Books I wish I had Written". Both lists had one of my competitors book at the top, so that it became the icon for the list itself. I didn't post these lists, someone else impersonated me and posted them in some stupid attempt to influence readers - like people care what I like and don't like (why are you reading this anyway?). What really pissed me off was the fact that I was impersonated. There are only four people with the last name Monson-Haefel on this planet and that is my wife, two kids, and myself. Why so unique? My wife and I took each others names when we got married. She was a Haefel (a rare name) and I was a Monson. Monson-Haefel is a married name. That listmania posting under my name was intention fraud, and in many states its considered Identity Theft - a crime.

As a side note, James Gosling was also impersonated on Listmania – funny how his list recommended the same book as mine …. Hmmmm.

Amazon.com wields a huge amount of influence in the publishing industry. By some accounts 25% of all books (at least in our field) are sold by Amazon.com. That's incredible market share. Because Amazon.com doesn't verify the identity of their members it's has unwittingly created an environment that encourages fraud and identify theft. What can we do? Well, other than complain to Amazon.com maybe not much. If anyone feels the same way that I do, and you have a good idea of how to stop Amazon.com's current business practices let me know. I'm all ears.

Personally, I think the best solution is for Amazon.com to validate the identity of its members by credit card. Why? Well, unless you have connections in the underworld it's pretty hard to create more than one Amazon.com account because each identity would be associated with a valid credit card with a unique owner. It would pretty simple to determine that two members are the same person - even if they used different credit cards (e.g Visa and MasterCard) for each account. What would be even better is if Amazon.com only allowed people who purchased the book from Amazon.com to post a review about that book. This would make it pretty expensive to post multiple reviews to the same book, good or bad.

Richard

This work is licensed under a Creative Commons License.