User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 We have several bugs at this point, that should all be part of the soon to be marketing.mozilla.org website. I think we should discuss how they can all be included into the marketing site, but left separate enough, not to be overwhelming to the user. It's an all out war. Tanks, Planes, AND bombs are going to be needed. Reproducible: Always Steps to Reproduce:
To get the ball rolling: I think marketing.mozlla.org should really be a hub for several sites: marketing.mozilla.org/personal for those who want it for themselves "switch campaign" marketing.mozilla.org/oem for computer manufacturers/OS developers/other OEM distribution methods marketing.mozilla.org/business businesses wishing to deploy Mozilla browser in their organization Each site should contain relevent *targetted* information on: Why to switch How to switch Tools/articles/informative information How to get help Case studies (from those who have been down the road) marketing.mozilla.org/affiliate for the new "affiliate program". As per discussions in that bug. By doing this, we will hit all markets, and target everyone, with personalized information. Individuals/Businesses/OEM have different needs, concerns, etc... we need to deal with them on their own.
Is this to be the official tracking bug for the marketing effort? If so, can it gain a meta keyword, full dependancies and a note to the effect? Thanks, Nigel.
I think the marketing subdomain may be useful for internal purposes, but I don't think end users will feel comfortable to be openly told they are being "marketed". I can't recall any other marketing effort in which the word is openly displayed. I wouldn't suggest a new subdomain, instead use the available mozilla.com domain as has already being suggested for all end user purposes, from here on: store.mozilla.com www.mozilla.com/switch mdn.mozilla.com (Mozilla Developers Network) www.mozilla.com/enterprise ans so on. In brief, constrain the mozilla.org to what it has served until now: development. Mozilla development, not development with Mozilla platform. marketing.mozilla.org is best suited for internal marketing projects, pilots, and so on, nothing going heavily outside or promoted. marketing.mozilla.org can't be Mozilla's face to the public, because of the name.
I support hiding marketing.mozilla.org from public view. Marketing is an organisational activity that is not revealed in any commercial or non-commercial organisation. It is the output of the marketing activity that must be placed in the public view; just as code changes are placed in the public view after a hacking session. We do, however, need a community area where collaboration can occur. Can I also remark that the central activity of marketting is: "To meet user needs successfully". Any marketing activity should start with an analysis of what those needs are. Therefore, is there a need for a market research plan first and foremost? That is effectively a design document and an action plan. If the target audience is not consulted before processes are put in place, then no real marketting is underway. Not all business/organisation development is marketing. Can Bart advise if there is a master plan at this point, and if any target audiences has yet been consulted? The community can help with surveys, fact finding, etc. We can also assisting with the fleshing out of that plan. Is the plan "open". Also this bug blocks bug 94490, which a) is not a meta bug and b) is a PR bug. In the usual case, PR is an output of marketing analysis, not the other way around. You can't decide what to say until you know who has needs that require statements to be made.
I think Comment #3 hits my personal feelings right on the head. It shouldn't be called "marketing" when it goes production. Simply because it's bad PR mojo. Perhaps the following architecture: http://www.mozilla.org - Central hub, easy to remember... consumer oriented http://get.mozilla.org - Below central hub... consumer oriented, consumer version of the /releases page. Archive of all versions, information on /why to /switch listing /advantages (subdirectories with '/'). http://affiliate.mozilla.org - Affiliate Program http://deploy.mozilla.org - For OEM/Commercial deployment. Mozilla Customization Kit, documentation, case studies, all sorts of goodies CC --> Bart Can we do this instead? I think it would be much better in the long run. Call it marketing.mozilla.org for the sake of keeping it "together". Perhaps even keep marketing.mozilla.org as a website for tracking mozilla usage, from a "mozilla community" perspective. But keep the above for the general public. Less intrusive sounding, friendly, and easier to navigate.
I'll add my 2 cents, as an ex-netscape employee and technology evangelist from '96 to '98. 0) The goal should be to promote Mozilla. But what does that mean? It means getting people and organizations to support mozilla.org's continued existance and using it's products. So the priorities and messages should fall into some sort of hierachy for priority on communicating concepts, something like this: 1) Mozilla Firebird and Thunderbird 2) Mozilla.org 3) All other Mozilla technologies 4) Mozilla community There needs to be a document on this, so everyone can reference it, debate it, and line up against it for alignment and measure of efforts. 1) KISS - keep it simple, stupid. Always promote mozilla.org/AREA and create an AREA.mozilla.org alias for those who can't remember. Limit the AREA namespace to be as small and concentrated for a marketing initiative or an audience as possible and to prevent fragmentation of efforts. Perhaps those four items listed above suggests the AREAs needed? Recycle each AREA with new events/promotions/content so that you can keep the old marketing customers interested who have already been part of a campaign. "Overload" each area. 2) Make marketing.mozilla.org for marketing coordination and documentation, but not an end-user area at all. Make it a launch pad. I'd rather land on that home page to get up to date (top down organization of efforts) and point me into detail newsgroups and bugzilla, rather than slogging (bottom up) through bugzilla and newsgroups first. 3) The purpose of marketing is to support sales. :~) I'll quote Jim Barksdale on this, "we are in the business of creating and keeping customers." So we want people to get the Mozilla product and use it. Every download is a sale. Every continued day of usage is a sale. Every improvement in the browser and community is a sale for mozilla.org as a whole. Allow multi-level-marketing switch campaign. Allow people to post up testimonies so anyone can see the case being built by people, not marketing types. Allow people to email their own testimonies to friends: "Dear Friend, I switched to the Mozilla Browser and in two weeks, I could suft the web faster, block spam in my email, and stop those annoying pop up ads -- FOR FREE! Want to try it out? Go to this link and download the latest Mozilla browser. Signed, your pal." 4) Increase access to information. Some of this may already be done, but it needs to be communicated and linked together better 'cause I'm not aware of it. 1) Make the newsgroups mirror to a mailing list (and vice versa)? I betcha a lot of people don't regularly look at newsgroups anymore. I can say I used to read Usenet everyday, but I haven't done so for years and that has become a habit. 2) Add a web based interface to the newsgroups. Now people can choose their preferred way to get and contribute to the same information, regardless of method (news:, http:, mail:). End brain dump for now. Sorry if this is a rant or unhelpful or needs to be divided up into separate bugs/issues -- it's a communication that I hope helps.
There was some recent (May 2003) discussion that may be relevant to this bug in netscape.public.mozilla.general : http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=3EBF18C3.7000705%40bclary.com&rnum=1&prev=/groups%3Fq%3Dnetscape.public.mozilla%2Btech%2Bevangelism%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D3EBF18C3.7000705%2540bclary.com%26rnum%3D1 Some other relevant issues that spring to mind: Using mozilla.com as an end user site is probably one excellent way of organising the mozilla web content. This could then be subdomained for specific groups of people - like press.mozilla.com, business.mozilla.com. Alternativly, simple directories could be used - mozilla.com/business and so on. This would allow mozilla.org itslef to remain virtually unchanged, which would be excellent from a 'cool uri's' point of view. However, it would, initially at least, make the end user site less visible than the development site. The reverse possibility is to shift all the developer oriented content to its own subdomain like dev.mozilla.org and place all the new end user oriented content at mozilla.org (+ appropriate subdirectories). The big advantage of this approach is that the mozilla.org domain is already well known as the home of mozilla. The big disadvantage is, of course, that bookmarks and links pointing to specific documents will break. In either case, a clear seperation is needed between developer content and end-user content - much more so than exists at the moment. This means, for example, that end user sites shouldn't be full of links to bugzilla - people complain about bugspam enough as it is without every new user who has had Mozilla 'marketed' to them posting irrelevant comments on bugs. Additionally, it should be /easier/ to find the end-user content than the developer content. This means that hiding end-user content in a subdomain is probably a bad idea.
Bart said in marketing-public before that the lawyer advised against having a separate mozilla.com We should separate user info from developer info. But until we get more people involved in user documentation, this is wishful thinking (so far I count only ~10 active user doc contributors: Neil Marshall, RJ Keller, Brian Heinrich, me, Asa, Ben Goodger, David Tenser, Timeless, kovu, Robert Mohr) > This means, for example, that end user sites shouldn't be full of links to > bugzilla - people complain about bugspam enough as it is without every new > user who has had Mozilla 'marketed' to them posting irrelevant comments on > bugs. I concur with James Graham. I think we should selectively comment out bug links in the release notes. Some bugs are WONTFIX, INVALID, or WORKSFORME becuase they are not really Mozilla problems and they confuse people. Will someone file a bug on this?
Depends on: 223359
Summary: marketing.mozilla.org → Marketing site and sub-projects tracking bug
<rant> Good grief! What in the world does the word "marketing" mean in the USA? "The job of marketing is to support sales"?? Marketing is a business philosophy that hold that the One True Road to sustainable profit is customer focus, i.e. serving customer needs at a profit. The very idea that marketing should be a secret activity carried out behind closed doors is a damning indictment on ... well, something. We develop code to produce software that helps people, and protects the Web. We do that in the open. Why on Earth shouldn't we develop code (marketing plans) that deliver that help to the unliberated in the open also? If your marketing plans have to be secret you really should be ashamed of yourself. You must be planning to trick or deceive people in some way. Shame on you. If by "marketing" you mean "find out what people want, and give it to them --- in a way that benefits us as well" you will find life much more satisfying. If we have marketing.mozilla.com as the paradigm of Open Source Marketing or Open Source Business (dealing with the customer transparently, openly and _honestly_ : imagine that!) then you will see the true power of the Free Software message, my young padawans. </rant> OK, I feel much better now. Srsly, I can haz mrktng job @ mozilla? Oh noes! I wont get payez. Want to know what your customers think? http://wiki.mozilla.org/Mozilla_Community_Surveys OK, it's not much, but at least it's a start.
You need to log in before you can comment on or make changes to this bug.