The Drumbeat 2000 & Macromedia Saga


This letter provides the core facts in Macromedia's handling of Drumbeat 2000. Please feel free to use this information as part of your complaint. Also available as PDF file or RTF file.

Consumer Response Center
Federal Trade Commission
600 Pennsylvania Ave NW
Washington, DC 2058 

To Whom It May Concern: 

This letter serves as formal complaint to the Federal Trade Commission on the possibly deceptive and unfair advertising practices of the Macromedia Corporation regarding the sale and advertisement of their product Drumbeat 2000.

 Macromedia acquired Drumbeat 2000 from Elemental Software in August on 1999 and hired many of the original Drumbeat program team. Macromedia began selling Drumbeat under their logo in September of 1999. During the summer of 1999 Macromedia made a number of public statements about the acquisition of Drumbeat. These statements were displayed on the Macromedia Web site as “The Elemental Acquisition FAQ” beginning in August 1999. These statements (see Exhibit 1) specifically suggested to customers that a new, expanded edition of Drumbeat would be developed. These pages continued to be published on Macromedia’s Web Site through April 24, 2000. This timing of August 1999 through April 2000 is of critical importance.

 Secondly, the way in which Drumbeat was marketed informed customers that the product would work with “Windows NT 4 and higher.” The Drumbeat User’s Guide specifically states on page 12 that the product will work with “Windows NT 4 and higher.” (Exhibit 2 - Drumbeat Users’ Manual page 12). This language is in common use in the software industry and indicates that the product would work with Windows NT 4.0 and future versions of the Windows operating system, in this case Windows 2000. For an individual who purchased the program, reading this indicated that they had made a good investment; the company intended to provide a product that would run under at least the next version of the Windows operating system. As will become evident, this was not to be the case. This is a piece of information that Macromedia has been distributed in their manuals from August 1999 through the present. 

In September, Macromedia released Service Pack 2 for Drumbeat, a software patch to fix certain problems and add some new features, which had been developed by the Elemental Software team. It added a few new features as well as introduced some new bugs in the program. Since then Drumbeat users have waited patiently for Service Pack 3 to solve the problems created by the bugs. Hundreds if not thousands of requests have been submitted to the company asking for these bugs to be fixed. 

In December of 1999 a number of customers raised questions about incompatibilities between Drumbeat 2000 and Windows 2000 Beta release 2. Macromedia responded that Drumbeat was not supported to operate under the Windows 2000 Beta 2. Macromedia’s statements at the time on the Drumbeat Newsgroup and posted on the Macromedia Web Site under Technote 2276 (Jan 06, 2000) were simply “Drumbeat 2000 is not compatible with Windows 2000 Beta 2” (see Exhibit 3 At the time many users believed (since Macromedia did not state otherwise) that this was a problem with the beta version of Windows 2000 not a problem with Drumbeat. Customers assumed that when the final version of Windows 2000 was released, Drumbeat would run on Windows 2000. However, as will be clear from the timeline below, Macromedia knew at least as early as December of 1999 that Drumbeat was not going to be compatible with Windows 2000 and the company had already decided that it would not build a software patch that would make it compatible. This information was hidden from consumers until April 2000.

Upon the release of the final version Windows 2000 on February 17, 2000, Drumbeat users learned from Macromedia staff that Drumbeat would not run on Windows 2000 (see Exhibit 3. When questioned about this on the various Drumbeat newsgroups at the time, Macromedia staff admitted that the incompatibility was a problem with Drumbeat not with Windows 2000 as is shown in these email messages from Jeff Von Ward from Macromedia Technical Support on the Macromedia Drumbeat Newsgroup:

Subject: Re: Drumbeat on Windows 2000 is trouble.
Date:  02/14/2000
Author:  Leif

    > DB and Win2000 don't go well together at this point.  Patch is awaited.  Has Macromedia acknowledged this yet?? 

Subject: Re: Drumbeat on Windows 2000 is trouble.
Date:  02/14/2000
Author:  Jeff Von Ward


  Yes, we have. Until there is a patch, we do not recommend using Drumbeat with Windows 2000. 

When questioned about whether the company would release a Windows 2000 patch, the response from Macromedia Technical Support was “yes we are.” Jeff Von Ward from Macromedia Technical Support made the following public statement on the Macromedia Drumbeat Newsgroup:  Please see Exhibit 3 for a number of email messages some of which confirm that a patch for Windows 2000 will be coming (while others are vague and elusive).

Subject: Re: Windows 2000 & Feb 17
Date: 02/15/2000
Author: Jeff Von Ward


No, we see it as a Drumbeat 2000 problem requiring a Drumbeat patch; this won't happen right away, though; these things do take time and your patience is appreciated. I think this is the third time I've answered this question for you, by the way, so let me know if I'm not addressing it in some way that you're  expecting it to be addressed. (Obviously we all want to see a patch and as soon as possible!)

 Certainly any reasonable person would interpret this statement as confirming Macromedia's intention to create a Drumbeat 2000 patch that would allow the program to operate under Windows 2000. Particularly in light of the fact that the Drumbeat Users Guide published by Macromedia states that Drumbeat will operate "with Windows 4.0 and later." In point of fact, the company had already decided much earlier that it was not going to create a Windows 2000 patch and consciously did not reveal that information when it was specifically asked about it. Windows 2000 compatibility is a critical buying factor for many users. Macromedia employees did not simply withhold information, they answered in a way that told users that a patch was forthcoming thereby preventing purchasers from making an accurate buying decision. 

On April 5 of this year, Macromedia announced that Drumbeat would be discontinued in June 2000 and that a new product, Dreamweaver UltraDev, based on the Dreamweaver architecture, would be released as a replacement. As part of the replacement program, current Drumbeat users would be offered a special upgrade price. This demonstrates the connection that the company was building in the minds of Drumbeat users between Drumbeat and the new product. This announcement generated both excitement and a great deal of concern among Drumbeat users. You can read a sampling of hundreds of comments from Drumbeat users in the Appendix of Exhibit 5. Drumbeat customers expressed shocked at the cancellation of the product, a feeling of being cheated by the company, and literally begged the company to provide a Windows 2000 patch. Some even talked about class action suits against Macromedia. Many Drumbeat users had spent months learning the program and developing Web sites with Drumbeat technology, based on the assumption that Drumbeat would be part of the Macromedia family of programs for an extended period of time as was stated in “The Elemental Acquisition FAQ” (Exhibit 1) - “the next generation of Drumbeat 2000 will contain a greater integration between Drumbeat and Macromedia’s existing products.” 

Drumbeat users were concerned about whether the Web sites created with Drumbeat would be usable in the new product. Little information was forthcoming from Macromedia until May 2000 about exactly what Dreamweaver UltraDev would do. It turns out that Dreamweaver UltraDev is not a typical "upgrade" to Drumbeat 2000 where the two programs are compatible; rather Dreamweaver UltraDev is a completely different product. Sites published from Drumbeat can be opened and modified in Dreamweaver UltraDev. However, because Drumbeat republishes the Web pages each time you make a change within Drumbeat any changes made outside of Drumbeat (by Dreamweaver UltraDev) would be lost. This is due to the fundamental architecture change between the Drumbeat product and Dreamweaver UltraDev. This has been confirmed by a number of Macromedia employees (see Exhibit 6). Here is what a Peter Moser, a Beta tester of Dreamweaver UltraDev had to say about the difference between Drumbeat and Dreamweaver UltraDev and moving Drumbeat applications over to the new architecture. He states that moving Drumbeat projects over to UltraDev will ultimately involve a complete rewriting of the Drumbeat application, an immense task for many Web sites and for developers who have built dozens of sites in Drumbeat. Peter’s remarks are confirmed by two Macromedia employees John Dowdell and Matt Brown on the Macromedia UltraDev Newsgroup: 

Subject: UltraDev Conclusions
Date: Fri, 12 May 2000 14:42:19 -0500
From: "Peter Moser"
Newsgroups: macromedia.ultradev


Preamble: I'm sure that following this post, my contacts at Macromedia will not be very happy with me. I regret that. Macromedia was very gracious in allowing us to beta test UltraDev and we are certainly grateful for the opportunity. I will be using UltraDev, but not for the role I had hoped. There's always version 2 to look forward to. I hope that the folks at Macromedia take this as honest feedback about the product and utilize it to make it even better.

  After getting to work with UltraDev for the past few weeks, I find that I will be reverting to a development methodology I had hoped to abandon. Having gained strong Drumbeat experience over the past 14 months and using Visual InterDev (v1 and v6) for numerous projects over the past 3 years, Drumbeat became my primary development web app development tool because of the power and time-savings it offered. Prior to Drumbeat, my project cycles consisted of using Dreamweaver to develop a site's look and feel and to build the foundational elements of the site. The resulting files were then incorporated into InterDev projects where database code was developed. A very workable process, but not as smooth as I would have liked. After getting hold of Drumbeat and becoming familiar with its development model, I found out that:

    - On average, comparable apps took 40% less time to put together in Drumbeat.

  - I was able to quickly put together a pretty stout library of customized SmartElements and Contracts that equated to an even larger time savings.

  - I garnered more work because I could deliver the product in less time, and therefore at less cost to the client.

  - While not a perfect tool, its strengths far outweighed it's weaknesses.


I had some trepidation about UltraDev after hearing that it would be based on the Dreamweaver architecture while at the same time being pretty excited because Dreamweaver is an indispensable tool for quite a bit of the work I do. Over the past few weeks, I put UltraDev to work in honest attempts to (1) migrate existing Drumbeat projects to UltraDev and (2) develop new projects in UltraDev. This is what I have concluded:

    - 'Migrating' Drumbeat projects will basically involve a complete rewrite of the app.

  - UltraDev will be useful for putting together project prototypes requiring database functionality, but it offers no advantages to me as a primary project development tool over Drumbeat or Visual InterDev.

  - The extensibility model of UltraDev is incredibly complex and will require far more time and effort than is economically feasible for me to undertake to replace the customized Drumbeat library I have developed.

  - UltraDev will replace Dreamweaver as the 'look and feel' tool for project development, however, Visual InterDev will again become my primary application development environment.

  - UltraDev's current database capabilities will provide existing Dreamweaver designers with some very nice functionality, but they are far too simplistic for me to use in extensive web apps.

  - ** The extensibility architecture of UltraDev is very deep and complex. As a result, over time, UltraDev has the distinct possibility of becoming an incredibly powerful web application development tool.**

  In the big picture, it's the last item that is the most important. For me, at this time, UltraDev does not deliver for me the level of functionality I need to give my clients what they need and pay me for. As a replacement for Dreamweaver, UltraDev delivers a familiar toolset while allowing me to get basic database functionality into my work. As a replacement for Drumbeat, well it simply isn't. As a tool that has the serious potential to become my primary development environment, I have no doubt about that. 

Peter M. Moser

Studio GP


Subject: Re: UltraDev Conclusions
Date Fri, 12 May 2000 15:42:03 -0700
From: John Dowdell
Organization: Macromedia
Newsgroups: macromedia.ultradev
References: 1

  Generally it's true that next month's release of Dreamweaver UltraDev won't immediately do all the things that Elemental Drumbeat did. I do think you'll find that the rate of growth (and the extent of growth) will be far more significant than before.

  Itt's definitely your call, though... it's good to evaluate the various technologies and see how they match up against a particular job you take on.

> 'Migrating' Drumbeat projects will basically involve a complete rewrite

> of the app.

That's true... Dreamweaver UltraDev won't convert existing ASP pages into its own smart elements. You'll certainly be able to edit these pages at the HTML level, and I believe you'll be able to add most types of new smart elements, but Drumbeat's own private editing structures won't be mirrored in the new architecture, that's true.


Subject: Re: LATEST DRUMBEAT & WINDOWS 2000 NEWS & More from MM

Date: Sat, 06 May 2000 11:09:21 -0700
From: Matt Brown  
Organization: Macromedia
Newsgroups: macromedia.ultradev
References: 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8


> I think what you're doing is great, this world needs more people like you.

> So we'll transition to UltraDev from DB, but what do you think of the fact

> we will not be able to import drumbeat projects directly, only the resulting

> ASP/HTML code? Isn't there something we can do about that?


No. There is no possibility of a converter given the current schedule and resources available to the team. We did look at that and made a decision not to proceed with that early on in the development process. The solution is to recode pages as needed and to create all new pages in UD or stick with DB.


 This shift in architecture is compounded by the fact that a number of the features in Drumbeat are not duplicated in Dreamweaver UltraDev. As announced by Macromedia, Dreamweaver UltraDev will not initially include a number of the E-commerce features found in Drumbeat E-commerce edition. What this means to Drumbeat users is that many users will have to continue to maintain E-commerce and other Drumbeat-built sites with Drumbeat for an extended period of time until 1) Dreamweaver UltraDev has the same features as Drumbeat and 2) until we have time to completely port our Drumbeat-built applications over to the new program. This problem is further exacerbated by the fact that Drumbeat 2000 will not run under Windows 2000. So thousands of Drumbeat developers are suddenly caught in a situation where they must maintain their sites on Drumbeat for months if not a year or more, and they can’t do it on a PC running Windows 2000. Macromedia was aware of this situation months ahead of time and chose not to inform customers of these facts. It allowed customers to continue to purchase the product without adequate knowledge upon which to base their buying decision.

 With the new product schedule to be released in June it is clear that Macromedia decided to discontinue Drumbeat long before April 5. I expect that a review of Macromedia’s records would set the date in the fall of 1999. The email responses in Exhibit 4 directly from Macromedia employees clearly indicate that the company decided to stop development on Drumbeat 2000 and to solely work on Dreamweaver UltraDev sometime in early fall of 1999. Here are a sample of those responses: 

Matt Brown
Organization: Macromedia
Newsgroups: macromedia.ultradev
References: 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8

Marc Garrett wrote:


> Matt,


> I'm sorry I throw out my back issues of some of those magazines because, if

> I recall correctly, the ads in question began running November 1999.

> Counting back five months seems to put you guys squarely in the camp of

> buying Drumbeat knowing that you would kill it off.


When we do an add for one app doesn't have much to do with when we run an add for another app. We knew soon enough after we acquired Elemental that we would not continuing development or marketing that spending any advertising budget would have been a bad decision.


Subject: Re: UltraDev Conclusions
Date: Fri, 12 May 2000 19:49:29 -0700
From: Matt Brown
Organization Macromedia
Newsgroups: macromedia.ultradev
References: 1 , 2 , 3


Bian Hogue wrote:


> The requirements should have been to port all of DB functionality into

> UD, in the _first_ pass. The coding requirement are already known.[snip]

> That was

> not the original intent. So if MM started this back last fall (like

> September), and will ship in June, that seems like 9 months.


You are correct on the time estimate, but, respectfully, you make the assumption that we had a requirement of having all the DB functionality in UD and that is not the case. Our mandate was to use the technology from Elemental to create a product to integrate web design and dynamic content in an application that we could upgrade and develop further than we could Drumbeat. We did that and the results are excellent. In the future we will continue to develop UltraDev but it will always be it'sown application, not a feature for feature duplicate of Drumbeat.


 The issue that Macromedia had decided sometime in 1999 not to develop a Windows 2000 patch was also confirmed in my April 21 2000 telephone conversation with Macromedia Vice President Beth Davis when she said that the program team examined Windows 2000 and determined that it would “take a team of programmers months to create a Windows 2000 patch so we decided not to do it.” (see Exhibit 3). While I don’t disagree with Macromedia’s decision on how to allocate their programming resources, the company maintained a policy of both misinformation and obfuscation about their product for months between the decision to discontinue Drumbeat and now. This practice of deception continued until April 5, 2000 when Macromedia announced the new Dreamweaver UltraDev product was going to replace Drumbeat 2000. It was only at this point that Macromedia acknowledged that Windows 2000 support would never be available for Drumbeat a fact they had known for months and kept from inquiring customers. Their Web Site continued to display this false and misleading information until April 24 (see Exhibit 1). It was only through my letter to the Macromedia President (see Exhibit 5) and my phone conversations with Macromedia employees that the false information was removed.

 Another interesting note is that several Drumbeat users have developed some simple patches to allow the program to work under Windows 2000. It seems strange that a company that posted 1999 fourth quarter revenues of $89,282,000 couldn’t put any time into solving this problem for their customers. 

I think as you read through the messages from Macromedia employees to concerned customers you will see a general pattern of disdain from the Macromedia staff. This is a company that has established a pattern of keeping critical buying information from customers. It does not bode well for how customers are to be treated in the future. This reply from Matt Brown at Macromedia is particularly telling, it shows that the company was aware of the disruptive nature the change in architecture would have on Drumbeat customers.

Subject: Re: Why wouldn't this work for everybody?
Date: Thu, 20 Apr 2000 12:36:05 -0700
From: Matt Brown
Organization: Macromedia
Newsgroups: macromedia.ultradev
References: 1 , 2 , 3

  Reed Sprung wrote:


> Comments below:


> [snip]

> In other words, no.  We don't care if DB users would benefit from a revised

> agreement with Unify.  We care about our main product line.  If this

> adversely affects a small percentage of our clients, who cares?  It would be

> very easy for us to rectify this, but after all, there's only 10,000 of them

> and half of those will update to UD anyway.  If we leave some destruction in

> our wake, so what?  It's not our responsibility, they're only customers.

> Lets worry about our focus here.  We'll just keep denying that there is any

> negative impact on Drumbeat users.  They'll eventually just go away. 

We are making these decisions to produce better software for the majority of our users. We don't like the fact that people are going to be disrupted, but we cannot help that that is going to be the case. We have all been in the same boat and the answer is never easy. We know how you feel, but in the end no matter what we do or how we do it we are going to have some users that move to UD and some that do not. Of those that do not, they will keep DB or move to products that suit them better. I know I for one, would rather have people getting on with their work than hoping against hope that there is going to be a resolution that keeps DB alive in some way. It will not happen.

Our responsibility is to you as a user and to the Dreamweaver users and to the users that are going to come in the future is to focus on the best application we can build. That is UltraDev. There is no way we or anyone else can possibly imagine that there is no negative impact on DB users. Change is always disruptive.


Subject: Re: UltraDev Conclusions
Date: Mon, 15 May 2000 00:03:43 -0700
From: Matt Brown
Organization: Macromedia
Newsgroups: macromedia.ultradev
References: 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12


> Second, why couldn't MM run DB and UD in parallel? Jim Grimble and

> possibly Tom Muck ask the same question. None of us is suggesting a DB

> version 4. Per a prior post today, I suggest that MM could have

> contracted out this short term maintenance.


We are not going to spend any resources that are not directly for UltraDev. If we could contract a DB maintenance team we could as well be using them for features on UD. Anyway, what maintenance needs to be done? DB works fine except for Win2k and there seem to be two separate solutions posted here.


> First, MM will retain a higher percentage of existing customers. One

> the big pushes in marketing today is to retain customers, because it

> costs five times as much to get a replacement customer.


That of course would be good.


>Second, this

> philosophy has the added advantage that large corporate decision

> makers are more likely to use MM, if they perceive that MM will not

> abandon them ...


No. Not correct. No corporate decision makers bought DB. For them, the only thing that counts is our support of DW and UD. Anything else is a waste of time for them. I know, we asked them.


> I suggest that MM's current

> plan does NOT have DB and UD in parallel at all. For example, when was

> the last internal MM maintenance done on DB?


Months ago. Again once the plan to do UD was done, any effort at all on DB was effort not spent on UD and we aren't going to do that.


> If any of these comments change MM's actions in the next few months

> great. I doubt that will happen. I reach this conclusion from MM's

> feedback (like yours). This is not the first time that MM said this is

> what we are doing and we will not change our plan. If that is not an

> accurate statement, then it is what I hear MM saying. I suggest that I

> am not the only one hearing that.


That is exactly what we have said from the beginning. We are going to build UD and we are going to stop selling DB. We plan carefully at MM and we always execute our plans. We are willing to listen to advice on how to improve UD in upcoming versions and we might be able to incorporate that in the UD plan. But any advice on DB is just something we can sympathize and listen to.


> My real hope is that MM takes the suggestions to heart for the next

> time MM wants to 'replace' a product. If MM had taken feedback like

> this to heart from prior incidents, then we would (all) not need to

> suffer so much. Why can't we learn from the past? Why can't we borrow

> someone else's good idea (like IBM's)?


We really understand this is frustrating, but we have been down the paths before. MM is over 10 years old and we have canceled products in a number of ways and the response is always the same regardless of the approach. It just doesn't help to phase products in. The best way is what we are doing now, fair notice and pour every penny and body into the new product. No secrets here that is exactly what we planned and what we are going to do. The trick is get involved in the plan for UD over time.


After reviewing the Federal Trade Commission practices I have found the following descriptions that seem to fit the current situation.

In interpreting Section 5 of the Act, the Commission has determined that a representation, omission, or practice is deceptive if it is likely to:[1]

·        mislead consumers; and

·        affect consumers’ behavior or decisions about the product or service.

In addition, an act or practice is unfair if the injury it causes, or is likely to cause, is:

·        substantial;

·        not outweighed by other benefits; and

·        not reasonably avoidable.

 Under these guidelines Macromedia has done the following: 

  1. Falsely advertised the product in a way that led customers to believe that it would operate under Windows 2000.
  2. Falsely advertised the product in a way to make customers believe that it was being developed into a more substantial product.
  3. Withheld critical information from customers about their plans for producing a Windows 2000 compliant version.
  4. Failed to provide adequate notice to customers that the product that they were purchasing was being discontinued.
  5. Has systematically and over an extended period of time misled customers.

 It is clear that Macromedia’s practices misled customers, affected their buying decisions, has created a substantial hardship and significant monetary loss for some customers, and was reasonably avoidable by the company. Macromedia continued to sell a product that it knew it was going to discontinue without providing customers with the proper information to make an informed decision about purchasing the product. Buyers based their decisions on a number of factors including information in the user’s manual, the company’s portrayal of how they would continue to develop the product on their Web Site. From my reading of this it seems clear that much of Macromedia’s approach has been deceptive as defined by the FTC and may even be considered as unfair. Here is what one Drumbeat customer reported: 

I am a developer who just put in my resignation at my full time job and planned to do freelance Drumbeat development. After a great deal of planning, I was slated to "go live" with my new business on June 3rd.  Only days after making this life altering decision, I found out about Macromedia's plans to discontinue Drumbeat.  This has been an upsetting development and I have been left with few options.  I can continue to develop with Drumbeat but using soon to be outdated software is a great disservice to my customers. It could also lead to great losses if I have to redevelop sites at my own cost just to update a few items. On the other hand, I could take the time to learn UltraDev (which I feel is by no means an upgrade to Drumbeat 2000) and cut my losses with the countless hours spent learning Drumbeat. This option would mean waiting until UltraDev is released (June, July, who really knows?), spending several months learning the product, and then I would finally be able to sell my services.  I would not be able to "go live" until at least November. Financially, this is not even an option.


When I first considered starting my own business, I was only slightly apprehensive and very excited. I had decided initially to choose all Macromedia products because of their quality and Macromedia's excellent reputation. Now their thoughtless decisions, clearly motivated by financial gain, have turned my dream into a nightmare. I looked to Macromedia as a company I could trust and am still shocked by the lies they have fed the development community. They need a hard lesson in respect for their customers. It seems like large companies always end up forgetting just how they got where they are. They wouldn't even exist if it wasn't for us, the customer.


Macromedia's actions have really made me consider how I will run my business.  After dealing with this much frustration, I understand the requirements my customers will have. I must be honest, fair, and respectful of their needs. In other words, everything that Macromedia no longer is...


The number of Drumbeat customers who have been affected by this or who have complained is staggering. Some are listed in my letter to the Macromedia President as well as many of their comments. Hundreds of other users have posted complaints on the Macromedia Newsgroups for Drumbeat, Drumbeat E-Commerce, and UltraDev. There were simply far too many complaints for me to include them all in these letter. There are also many other Drumbeat customers who do not use these online resources who have also been adversely affected. It is estimated that there are about 10,000 Drumbeat users. 

I would appreciate your assistance in filing this complaint and in informing me what additional action customers can take with the company regarding refunds or compensation. I can be reached at the address above. Thank you for your consideration of this matter.



                                                                                                Rick Curtis

[1] http://www.ftc.gov/bcp/conline/pubs/buspubs/ruleroad.htm