Welcome to future home of Freedomware Marketing. The Tux Project is going to be shifting gears a bit. This site is set to become a grass-e-roots website where we can all work together to openly collaborate on promoting the use of Freedomware in our local communities. Whether you are a business owner who uses or offers Freedomware solutions, or an individual enthusiast. You will find that this is the place for you to share your promotional ideas and work together collaboratively in order to make them a reality.
Intro to Very Big Project

This will serve as an intro to a very big project.
Here are a bunch of elements of the project. Keep in mind one thing. Linux is about "you" (or "me" depending on pov). It is meant to be shaped into what "you" need/ into what you desire.
-- If things work out, on average, people will like, know about, and use Linux more than Windows. This won't happen overnight. You can even say that I am just stating what many might believe will ultimately come true. Ah, but the rub is that we are going to play an important part in that happening. We will see it. We will partake in it along with our neighbors everywhere. We will get this sucka moving! [getty up!]
-- There is going to be a disciplined and concerted effort to take marketing to a new level for FOSS projects. We will help organize FOSS projects that like what they will receive with the deal. We will build a few standards so that everyone knows what they have to do and can work in parallel. We will work closely with Jack/Jill. The interaction will be disciplined and lead to more user friendly applications and motivated Jacks/Jills. Projects that put the most into making this work will benefit directly the most through greater participation from Jacks/Jills.
-- As the community takes off (with many a Jack/Jill), in its wake will be left an infrastructure to surpass any Windows ecosystem that has existed to date or likely will ever exist. [This is the plan anyway.] The project will grow as much as possible in a localized fashion. Local support and focus ensures the greatest appeal to the most number of people (through things dear to heart and relevant and sustained locally). This can drastically improve the percentage that are able to start up on Linux and that will stay with Linux. Much will be shared globally, don't worry. Also, I anticipate the major brands (eg, distro brands) to develop huge memberships from supporters. Spun distros and apps will be common, but usually the majority of the base system will belong to one of the major branches. There is room here for lots of folks just like the economy supports lots of types of restaurants. Variety is the spice of life, I was once told. To deny it is futile. An analogy (that I won't think too deeply about) would be to liken distro successes to the restaurant franchise model. It won't be Ubuntu or Fedora or Debian or Slackware for example, but more like X-buntu, X-edora, X-ebian, X-lackware, etc.
-- We will leverage P2P and other distributed tools. We will share (clone) websites and much more. The participants will bear the costs incrementally so that this is sustainable and scales. Where CD's are distributed, I suspect that individuals will grow this roughly "neighbor to neighbor" in many cases, with updates and other sharing, once the audience matures a bit in sophistication, coming from digital downloads instead of costly CD/DVDs (eg, torrents in many cases; keeping in mind that a minority of the ingredients of the secret sauces, but the defining ones, (the spices if you will) can be terribly compact and come from a central server to then be cooked into the "meal" on the users PC's quickly).
-- Consider 3 phases with an unofficial goal to reach say a million participants for each phase (the first phase should have many more entries than the other two). That is, this project being described here currently can be said to be composed of 3 phases (it could evolve into more, fewer, or something significantly different).
-- Here are some *possible* common themes for the 3 phases. The 3 phases' unique qualities will be described a little later on.
-- We will start somewhere but the depth of the project will grow to encompass the interests of people of all walks of life. This is not only natural, but is really how we have to think when you consider the vast work ahead. There are many people of all types. Many would not ordinarily give vanilla Linux a second look. Whoever developed the saying that the customer is the boss was surely thinking about this task ahead (to take serious share from the Monopolist (hopefully 100%), one person at a time, quickly and efficiently).
-- We *may* hold frequent prize drawings/raffles. People's accumulated points can be dedicated as they wish towards the individual announced lotteries (there will also be freebie surprises and games over time) based on how many chances they want. An example might be "one ticket = 1000 pts". We will raffle things worth real dollars (eg, over $1000), as well as services that in part can be produced by the community (but specifically for the winner). At this point, I am not worried too much about where the money or donations will come, for there will be many opportunities for spontaneous, localized, creative fits. Some dollars may come from fees, from business transactions, from advertising revenue, from donors, from donating contests, talent shows, and bake sales, through creative use of people's time for $0 upfront costs, etc.
-- I will describe various sources of points more specifically under the Phases sections below. Generally, I expect MLM scenarios. What I mean is that to encourage individuals reaching out to others, we can award points not only for the actions "you" take but, to a smaller degree perhaps, for the actions that others that are related to you take (related can mean that you signed them up for example). As always, we have to try and be careful about preventing cheating and about being able to identify actual participants. Nothing is perfect, but I have hope things will generally work out (a point system and a ticket and lottery system helps out.. the old, "it only takes one ticket to win the MegaMoney").
-- Generally, all bits/bytes are free and the focus of most things should be to allow end users to add or subtract as they see fit.
-- From the newbie stage where everything should be extremely simple and easy to do, to intermediate stages, to later stages, we will continue to develop better tools for interaction and individual growth. Easy means obvious and clear. It means clickety. It means videos. It means vid demo guided surveys. It means archives of many questions (to match what they might be wondering) resolved and easily accessible/indexed. It means docs targetted to different levels of sophistication and pov as well as using various approaches.
-- Beyond being easy as much as possible, we want to make sure the system is opened up as much as possible. This is Linux/FOSS, keep in mind! Alongside the easy stuff, we will have tantalizing peaks and pokes and simple to use tools allowing one to explore at a deeper and deeper level.
-- We may also want to keep in mind recycling contexts. As already mentioned, we (meaning the growing community) will eventually reach out and participate in almost all activities of interest to anyone. Recycling is both a Good Thing and provides a useful theme in many scenarios. It's only one of many areas, but I thought I'd mention it specifically at least once because it's a fairly large topic (like schools) that may play a role repeatedly, and I don't know where else to bring it up.
-- Phase 0: This phase is not part of the three. I guess it could be, but you will see later that it does not fit in exactly with the general theme of the 3 phases. If the GPL can have start with freedom 0, this project can start with phase 0.
-- The idea here is to start off by building a base to work from. We already have a base -- FOSS+community as we know it, duh -- but anyone that wants to participate will probably benefit to work on an initial seeking/recruiting of those that will easily be attracted to this project and take it to heart. The idea is to build a local base first. Discover who the other nerds/geeks in your area are. You will find people of all sorts of backgrounds may be attracted to this, including hungry and neglected Windows pros. We'll try to find messages to address as many potential audiences as possible for this and other phases.
-- I recommend some things. After you have a decent beginner's website, you advertize the url. Put the thought into the website ahead of time and then let it do as much of the talking for you as possible. Also, have some infrastructure set up already (db backend necessary for tracking). The website would be primarily a global project we all share in.. with any local or other variation (personal touch) done by the particular "recruiter" (that would be you reading this long very big project intro). Currently I am looking at AGPL 3.0 as the license of choice for most of the website content. Just a though. I don't really know what will work best.
-- Also, for websites, I would like to make a few things a priority. Where possible, very nice realistic artwork. Overall, simple website, possibly divided into static pages and dynamic content so that this can be hosted from different servers. I'm not sure if this logic follows, but I do prefer to use offline scripts to update static pages (eg, from the prior hour's or day's db entries) than to have a bunch of pages be generated on the fly just for the sake of little tid bits like showing how many nanoseconds it took to generate the page. Maybe we can even then have a chunk of the website hosted using a speedy webserver (faster and less resource hungry than apache with 100 modules loaded). I have my eyes set on "large number of hits potential/protection" and "allow those with limited budgets to participate with these cloned websites hosted through feeble hosting programs." Dynamic pages and pages that update the db should be very short. The static pages can use the fancy artwork since much of this would be cached on the user's PC and throughout Internet proxy/cache servers. Javascript may work in either case since the work is done by the client and I think may be cached like any other resource. [So by "static page", I might be referring also to some included javascript.] More technical discussion can be had later, as these are just some random thoughts related to which I have not even done much experimenting.
-- There are many places to post advertisements with urls.
-- We can walk and leave small cheap ads door to door (eg, cut up an 8.5 by 11 in sheet into many pieces to distribute). For this case, try to do a bunch at a time and take some statistics such as approx where you dropped what ad message and on what day/time. Keeping records can facilitate you improving your ad content over time for effectiveness based on feedback and observations. [I am considering also how it might be feasible to map each city block online, perhaps using gov or google/yahoo maps as a reference point.] If you do a few hundred or thousand(s) in one area and then move to a removed neighborhood and repeat, you can seed in scattered places, making it easier that those that join you later have places near their homes where they can help out. Otherwise, everyone will be bunched up, meaning that you will lose some participation since not everyone is willing to travel far (gas prices and lack of familiarity and inertia).
-- have a local mailing list in place, especially for these more enthusiastic early recruits. You can (should) get to know these local people. They will allow you to scale. 1000 homes times 1000 people equals 1 million homes.
-- We will have various webpages depending on the message and target audience (eg, the early recruits start off with a different pov). In any case, look for very short or easy to remember host names. Make everything easy and short so can fit in small ad areas and be remembered. A simple url on a page w/ or w/o a few provoking words may generate a bunch of hits depending on the url chosen and other context.
-- Some newspaper or other ad space may be worthwhile to you. Really think you words carefully if you take this route (to save on $$$ and attempts), and please share as many results as you feel comfortable sharing with the rest of us.
-- Develop a plan, angle, website, pitch, etc for SCHOOLS SCHOOLS SCHOOLS. I expect this will be a huge source of motivated individuals (relatively speaking.. ie, bang for buck). Schools: probably high schools (large numbers, not too young, and open to experiments) and universities (more sophisticated environment). Schools are a natural sell on FOSS. Schools can serve a vital role of providing equipment or "office space" for face-to-face interactions (with each other and with noobs). You may be able to start and leverage teaching classes to each other and to the public (see http://thetuxproject.com/node/303 and http://thetuxproject.com/gnu_and_tux_went_to_school ). As will be clearer when I say more detailed things below about the 3 main phases, there is a whole lot of room for heavy duty getting down and dirty with FOSS apps and distros. Makeshift or more established "computer laboratories" are what we are after. "Bond" with your associates. Pretend you are Edison and they are your staff (they can pretend the same thing with switched roles). Having access to this will serve to unite and motivate those getting together to discover and advance many facets of this project more efficiently. Over time, other types of office space (funny movie, btw) will become available as the active participants grow in number, as the network grows. Office space can also serve roughly as what Apples stores serve, plus a whole lot more.
[Alright, soon I am going to take a break and end this for tonight. Quickly, I'll cover the 3 phases. Later, I'll pick this up and edit this posting to flesh out more details.]
-- Phase I: End users will have a fixed set of applications/projects to sample and fill out surveys (eg 10). The projects will be random with larger more important projects (and those of groups working this) appearing more frequently. Projects will design their survey. Survey to focus on usability but may ask a few open ended suggestions (eg, for features). Videos should be a part of this. Surveys may for example ask the user for some tasks, then ask again after showing video demos. Some open ended feedback is likely.
-- Points will be given. Users need not do phase 1 first. Users will register when they do this (password/username/zipcode perhaps and a few other things maybe are required). They will sign up in the first of the three distinct million+ slot sign ups. Users will be allowed and encouraged to continue with more surveys for fewer points. They can do this whenever they get to try an application or want to use the surveys/tutorials to learn a new app and want some points. Noobs may see this as a chore initially, but after trying things for a while and playing with phase 2 and 3, I think many will be motivated to come back.
-- To enroll, I think we may want to require they have been a newbie for 1 year. I think everyone should participate, but I would like a goal of 1 million fresh users. Maybe then allow all to do phase 1 but only count noobs within the 1 million goal.
-- There is much that can be done here. We may integrate surveys (and points) into products/projects from phase 2 and 3 as time goes on and these grow.
-- The random apps/setups may be doled to users after they sign up (vids will show what to expect and why what phase 1 entails). These apps chosen will be recorded for record/control and points purposes (worth more points). Remember we have potentially many projects that want feedback so we have to manage the weighted random selections carefully considering that not all users will reply adequately.
-- The user will likely install a special item from a repo or else download something (eg, torrent) that will set up their distro for the surveys (eg, populate the desktop and change settings, etc). A bash script plus some regular config/text files could be a simple way to produce these effects.
-- We can achieve some amount of distro agnostic effect by providing standard "API" to the app surveys. The distros that want to participate with that app can then write the script or do the package that will create the proper setup. Vids and demos may be done partially by the app project and partially by the distro project. This way we can distribute many distros (or the end user can pick and choose online) without compromising the survey/Phase 1 portion of the project. Also, this can serve as a warm-up for the other 2 phases :-) .
-- Surveys/tours should help identify those users that aren't paying attention (half-hearted responses) as well as those really not paying attention or trying to automate or game the system. We want to prevent people from wanting to cheat (which is not necessary really when they think about it.. unless they have bad motivations). Getting to the end should itself likely imply a certain amount of diligence by the end user (eg, click X to proceed or do Y task). Just like failed logins for security, the survey and demos should take a certain amount of time. I also encourage the app community to continually update and tweak or outright redo the surveys (as they grow beyond aging surveys, as well as to decrease the odds of being gamed).
-- We will develop standard interfaces for all of this across projects and surveys. We will both have stats we can keep as well as open ended responses that will be relayed (with the stats) to the projects.
-- Phase II: In phase 1, the user got to try out a Linux and hopefully some cool setups of some cool apps. They got an intro, a taste. Plus they got some points in a bid to win some prizes. All for free (well, we all know the saying.. Linux is free if blah blah your time). They may have even done phase 1 in anticipation of phase 2 and 3. They may want to share the LiveCD (or installer) free goodies with others (increasing their point potential in the process, MLM style). As they see what is going on and that they interests may be advanced through community leverage, they may also want to contribute to phase 1. Feedback, for free stuff that grows as you want and need, can be a bit exciting to give. Especially if the feedback surveys come with tutorials.
-- OK, enough about phase 1, but first an aside related to this last section discussion:
-- There are many ways to get others to try out these distros. Exactly how and whether a LiveCD or DVD or an installer or a pre-install or a download or on a friend's PC or on a demo PC or through whatever means, and exactly which distro base, is a detail that will vary and I will leave be for the moment. If discs are given away, they must be funded somehow, keep in mind. Do see this though as a warning: a comment called "An injunction on antitrust grounds" at http://www.linuxtoday.com/infrastructure/2008041300326NWMSSW
-- So phase II is where the user easily builds as many custom LiveCDs as they want. The deal is that they are bound by the pre-constructed selection set out for them, but this is only because it takes time to create a theme and set of knobs to be tweaked into a distro with a consistent theme or attitude, done through an easy interface.
-- We will eventually cover just about every theme, category, or interest known to mankind as we develop interfaces to customizing themed distros spun from debian, fedora, etc, bases. Thus the theme is "plugged in" to any distro that wants to implement the "back end." .. A distro for lawyers of children custody cases who happen to love the color brown and American Westerns and Indian music. .. for sheep lovers that also love Latin and yodeling. ..for those wanting a distro focused on crib notes in their study of Econ 101 or advanced French poetry (taught in Russian). [Hey, a distro for every university course under the sun!]
-- Phase 3 is the phase where the user gets points by giving back to the community. Examples are by helping to develop phase 2 setups, perhaps by taking charge (becoming the maintainer) of some aspect of or a full specialty distro flavor to be used or already used by phase 2. There may be contests to see who contributes the best of X
-- Roughly, you design distros around an interest you want. There is artwork, code, music, app setup, app selection, etc, and any other combination of these and other things that go into the general design. Those with a technical bent can help turn these ideas and designs into auto setups useful for phase 2. We want to expose as much as possible. Let the distro be the end users palette. Let the app devs open up and expose as much of their apps as possible. For example, I'd like to develop a simple standard or procedure to help expose all parameters in games to allow the users to tweak any of them (including to recompile efficiently where unavoidable). Also we can build guides into the source code in interesting places (eg, to affect the physics or scorekeeping or abilities). Game artwork and art-related creations as well as code params should be completely detailed in easy docs/demos and wrapped in intuitive GUIs used for changing values or code or art/music/etc. Who says that end users don't care about code?! We will see.
-- We will continually improve user tools for doing these activities/jobs.
OK well, I'll clean up and add more flesh later.

Evolving our current Linux lineup to suit varied user audiences
[If this project is not making sense, let me know and I'll try to clarify.]
As long and drawn out as the above posting may appear, there are so many details missing that will be filled in on case by case basis as we move to collaboration and implementation. I will probably start up a wiki later on to hold specific app/distro related suggestions related to this project.
One approach I favor (theory not yet put into practice) is not to hype the apps at all. Apps lack whenever they feel different to the particular user, handle closed formats any worse than the user is accustomed to, etc. There is plenty about this project to entice. Routinely hyping apps (as stand alone products) any further beyond what is merited taking a conservative viewpoint will completely undermine the expectation and interest in this project (in what is possible as the user may wonder in the early stages of community involvement) since the user will clearly recognize that hype once s/he starts using the app. Many will be turned off. Remember, "different" is worse in the initial stages (unless the app just rocks). We are going to have to get used to possibly (for example) looking at a rating system that gives low values even for apps we like (none of this 9.9, 9.8, 10.0, 10.0...). Of course, constant growth and new features means that a user turned off today can be re-enticed tomorrow through some other user taking a better approach and showing off something new and neat.
There are many dressings/facades that many apps can take on or improve. I don't see why apps can't have different feels to them [ditto in an even greater sense for distros]. After all, usually confusion is just a matter of input section rearrangement (plus adjusting the way a few things work) and string text wordings. As mentioned above, there will be a focus to give the users the interface they want. There will be a lot more hand holding put into place (a permanent more sophisticated help system jump started by the surveys-tutorials from phase 1). The L&F should evolve through the feedback and should preferably not be hard coded. Have 10 L&Fs. Why not? Why start a whole new app or consider a hefty fork just to move things around a bit. Most apps have sufficient libraries so that a new app can borrow a lot, but in general we can organize development better so that variation is anticipated and cooked into the fold more. For example, greater use of decentralized code version control, besides allowing for better scaling, should make it easier for more cooperating forks to exist, meaning that more end users will be satisfied. We can also consider things like mappings to a canonical app description. Thus users wanting support of some sort can click a button and the support personnel (eg, experienced forum volunteer) immediately knows what they GUI looks like and functions based on the mapping to the canonical standard for that project. [This may not work if those spinning new apps don't update the maps.. but I don't anticipate a problem in the general case.]