[ It should be noted by anyone reading this document that it consists of ideas that may or may not be implemented by the Techno Democracy Project. It was intended only as a collection of brain storming notes, not as a blueprint cast in stone. Regardless of the language used to describe the ideas, they are all merely options for TDP, and others, to consider. As time as goes by, it may become apparent that some, many, or all of the ideas are not suitable for implementation. However, either way, this document can be a catalyst for further thought and discussion on the topics covered. ]
TD & TDS Definition
One of the main goals of the 'Techno Democracy Project' (TDP) will be designing
and building a world-class online voting system. But there will be other goals
related to other types of online systems which can support
'Techno Democracy' (TD). A definition for these systems, which will be
generically referred to as 'Techno Democracy Systems' (TDS), could be 'any online,
computerized system which supports, enables, or enhances one or more processes
in a democracy-based government'. This is a broad definition which goes well
beyond electronic voting systems and could potentially include just about
any process in any democracy-based government (organizational, local, state,
provincial, regional, national, continental, or International) which can be
Tools & Mechanisms
To start out with, one of our main focuses will be on
electronic voting systems. But with time and additional resources, we will be
able to venture into many other types of TD systems. Here is an overview
of some other types of TDS which could potentially be built by TDP.
Legislative Branch Tools
Issue Mapping Tools - When dealing with voting in legislative
bodies, it is important for voters to have a good understanding of the issues
which are being voted on. However, due to large volumes of issues in some
legislative bodies, it can be difficult for voters, advisors, and
representatives to obtain a sufficient understanding of the issues under
consideration. Therefore, TDS tools could be created which enable faster
and easier ways to understand and to track issues, their variations, and
their ramifications. TDS techniques could include using 2-dimensional and
3-dimensional graphic representations of Issues, their major and minor
variations, and their ramifications.
Position Mapping Tools - In Representative legislative bodies, it
is common for both proponents and opponents of specific pieces of legislation
to attempt to build a coalition to support their side before the vote occurs.
To help this process along TDS tools can be
used in conjunction with the Issue Maps
to Map out each voter's Position on each Issue. This could be used to
help visualize and track which side and which variation of each Issue is most
strongly supported, and to assist in determining which voters, advisors, and
representatives would be the best candidates for deal-making, vote-trading,
Bubbling Mechanisms - In any form of democracy, everyone is clamoring
to be heard and to get their own issues to the top of everyone else's agenda.
This introduces a high degree of 'noise' into the process of locating
worthwhile legislative proposals to vote on. To create a more tolerable
'signal-to-noise ratio' and a more productive environment, a 'bubbling
mechanism' can be created. In this mechanism, any issue, proposal, position,
comment, vote, or any other online content which can be linked to will be
considered its own virtual 'bubble'. Each voter, advisor, and representative
then has the ability to help determine the value of each of these bubbles to
themselves, their constituents, and to everyone else.
If any given issue-bubble is worth-while and deserves more wide-spread
attention, then each voter/advisor/representative can incrementally increase
the size of that bubble by voting for the bubble to 'bubble-up' and by passing
it on to a group of their own personal contacts (via the bubbling software).
If those people, in turn, feel that the issue deserves wider attention, then
they will pass it on to their own contact list. And so on. The more people that
pass-on an individual bubble-issue to other people, the 'larger' it becomes
and the higher-up it bubbles in comparison to all the other bubble-issues.
As issue-bubbles rise higher and higher in the bubble-space, then the more
attention they will draw.
If any given issue-bubble is deemed not worth any further attention, then
each voter/advisor/representative will mark it to 'bubble-down' in the
bubbling software and would not pass it on. The more 'no-further-attention'
responses an issue receives, the smaller its bubble gets and the lower it
sinks in the bubble-space. As issue-bubbles get smaller and smaller, the
less and less attention they will get. Effectively reducing the 'noise' in
the overall TDS.
One way to further reduce the intra-TDS noise level is to create the bubbling
software so that voters/advisors/representatives can set their bubble 'in-box'
to only accept bubble-issues passed to it from specific, pre-approved people
or groups. This would effectively eliminate 'spamming' in the bubble-space.
People who send bubble-issues to individuals who do not want them (and have
bubble-filtering turned on) on a repeated basis, could loose their
bubble-up/bubble-send privileges on the system.
One very important benefit of a bubbling mechanism of this nature is that it
allows *anyone* to submit legislative ideas, issues, and proposals into the
system. It, in effect, democratizes the legislative process. The bubbling
mechanism, thus, totally prevents any individuals or
groups from blocking issues which they are not in favor of (as happens in
present-day legislative bodies). It also prevents other types of blocking
measures which are used in present-day legislative bodies and insures that
important issues actually get voted on. It would contribute significantly
to 'leveling the playing field' in the legislative arena.
Centralized Workspace - To help voters/advisors/representatives be productive in a TD environment, it will be important for TDP to come up with some sort of centralized workspace for all the TD tools to tie-in to. It appears that the best route to pursue is creating a full-featured, fat-client program as the primary access method, which is as easy to use as an email program. Then use a web-based browser interface as a secondary access method, with only basic functionality.
Dialoguing & Debating Tools - In legislative chambers in the physical world, it is common practice to have open dialog and debate on issues being considered for a vote. In cyber-space legislative chambers, this could be challenging without help from tools specifically designed for this task. Usenet newsgroups, online bulletin boards, and chat rooms all provide free-form dialoguing spaces. However, none of them are custom suited for dialoguing on, and debating the merits of, legislative proposals. This is another area in which TDP could create customized tools which would tie-in to the other TDP tools.
Vote-Trading & Deal-Making Tools - It is current practice in some legislative bodies for Representatives to engage in what could be referred to as vote-trading and deal-making, in order to get their highest priority legislative proposals voted into law. No money, goods, or services trade hands, but votes are sometimes cast in a particular manner in order to obtain a returned favorable vote on a different issue.
'Legislator A' trades his/her vote on 'Issue 123', in exchange for
'Legislator B' to vote a particular way on 'Issue 456'. 'Issue 123' is more
important to 'Legislator B' and 'Issue 456' is more important to 'Legislator
A'. Therefore, each Legislator trades a vote which they deem to be less
valuable, in exchange for a vote which they deem to be more valuable.
Our impression is that this is common practice and is an effective way to
give one's highest priority legislative issues the best chance of becoming
law, even if some people feel that it is inappropriate. Vote-trading and
deal-making TDS tools could be created to connect
voters/advisors/representative by matching up 'votes-available' with
'votes-desired' for any given issue.
However, due to their potentially controversial nature, there would need
to be a way to 'turn off' or 'block' the use of 'vote-trading' and
'deal-making' tools in any given voting system.
Coalition-Building Tools - If vote-trading and deal-making
functionality is enabled on a TD voting system, then
coalition-building will also be taking place. It would be helpful to
build tools to help facilitate the coalition-building process. Current
day coalition-building practices could be studied to determine what type
of functionality would need to be created for these tools.
Strategy Tools - In addition to coalition-building tools, it
would be helpful to have tools for voters, advisors, and representatives
to plan, track, and implement strategies to help insure their highest
legislative priorities have the best chance of becoming law. Competitive
analysis and most-effective-way-to-vote-to-achieve-a-specified-agenda
analysis (the obvious way is not always the most effective way) tools would
be possibilities. Analysis of current political strategic practices would
yield further ideas for implementation.
Executive Branch Tools
The Executive Branch of a government, with its various offices, agencies,
and ministries, creates policy and decisions on a regular basis which are,
in effect, minor pieces of legislation. These offices, agencies, and
ministries operate under 'umbrella charters' issued to them by some previous
piece of legislation.
Even though the General Public is not directly involved with creating
Executive Branch decisions and policy, the General Public is directly
affected by these actions. Whether it's the agency implementing the Tax
System, managing the Social Welfare program, over-looking Natural
Resources or some other governmental function, everyday people are affected by these agencies' decisions and
want to have input into their policy creation, implementation, and
TDS tools could be created to help these agencies communicate with, and
interact with, the General Public. This would allow these agencies and
ministries to operate in an Integrated way with the General Public, instead
of in an Isolated way.
However, it should be noted, that the purpose of Executive Branch TDS
should *not* be to micro-manage the Executive Branch of a Government.
Micro-managing our public officials will not help them do their jobs, but
will instead make their jobs much harder. A productive balance will
need to be found to maintain a healthy level of Public input and a reasonable
degree of empowerment for our public officials.
Governmental Executive Branches would need to be studied to determine what
types of TDS tools would be appropriate and beneficial to create and be
utilized with this branch of government. All votes cast on issues being
handled by an Executive Branch would be for guidance-purposes only, and would
be non-binding in nature.
Judiciary Branch Tools
The Judicial Branch serves as an important check & balance to the other two
branches of government. However, just as with the Executive Branch, the
Judiciary does not work best in a vacuum. Interacting with the General Public,
as opposed to being Isolated from it, helps the Judiciary interpret law
in ways relevant to our rapidly changing world.
Just as with Executive Branch TDS, Judicial Branch TDS would be for
guidance-purposes only and would be non-binding in nature. The exact
requirements and purposes of Judicial Branch TDS will need to be determined
at a future date and time.
PoliBots & GovBots
Another TDS concept, which is a bit 'out there', is 'PoliBots'. In computer
software circles, software 'robots' (which perform specific pre-defined
functions autonomously) are referred to as 'bots' or 'agents'. 'PoliBots'
would, as the name implies, be 'political bots' -- able to perform political
and TD functions in an autonomous or semi-autonomous way.
In small legislatures, PoliBots would be merely a novelty. However, once the number
of Voters, Advisors, and/or Representatives moves into the hundreds, PoliBots become
useful. When Voters, Advisors, and/or Representatives number in the thousands or
millions, PoliBots become essential. Large-scale groups simply can't
support all the interaction needed for a properly functioning legislature, without
the use of assistants - either human or computerized.
Much of the above-mentioned TDS functionality could be built into specific
PoliBots. For example…
Deal Sniffers - Could search Position Maps looking for people to do
vote-trading & vote-dealing with.
Affinity Sniffers - Could search out people with the same/opposite
Position on multiple Issues.
Coalition Sniffers - Would attempt to find coalitions which are being
built so that they can be
Joined (by a voter/advisor/representative),
Merged (with a like-minded coalition), or
Opposed (by a voter/advisor/representative or coalition).
Deal Makers - Could negotiate vote-trading deals with other People or
other Deal-Making Polibots. Would use pre-set parameters, strategies, and
Coalition Builders - A meta-bot. Would use high-level parameters,
strategies, and triggers. Would use Affinity-Sniffers, Deal-Sniffers,
Coalition-Sniffers, & Deal-Makers to build a coalition.
Opposition Sniffers - Would attempt to sniff out what the opposition
is doing, how strong it is, how fragmented or united it is, what opposing
coalitions are being built, etc.
Deal Trackers - Follows through on monitoring deal participants to ensure
everyone is meeting their commitments.
Other Types of Polibots - could be built. As the cliché goes, 'necessity is the
mother of invention'. So, whenever it becomes apparent that a specific type of
polibot would be useful, somebody will build it.
Also, just as with the Vote-Trading and Deal-Making tools, some
types of Polibots will probably be controversial and not universally welcomed.
TDS will need to have the ability to 'turn off' and/or 'block' specific types of
Polibots which are not welcome in specific voting jurisdictions or legislative
GovBots - would also be software robots, just as PoliBots are. However, they would
be for performing tasks related to government data and government services, instead
of relating to political processes.
Different sized voting systems are needed for different purposes, but they all share common voting functionality. For this document, it's useful to break voting systems down into three general categories -- High-End/Industrial-Grade, Medium-Sized/Organizational, and Low-End/Personal-Family-Workgroup.
[ TDP may not produce different systems, based on system size. It is more likely
that a single system will be built so that it is highly configurable. Then specialized configurations, complete with
unique install and usage procedures, would be created for different purposes. ]
High-End / Industrial-Grade
High-End/Industrial-Grade voting systems are big, complex, full-scale, 24x7x365, National, International, Continental, and Regional in nature. These systems will require a relatively high degree of technical knowledge to setup and maintain.
Medium-Sized / Organizational
Medium-Sized/Organization voting systems are moderately complex and require a moderate amount of technical ability to setup and monitor, but will not necessarily be actively monitored nor run 24x7.
Low-End / Personal-Family-Workgroup
Low-End/Personal-Family-Workgroup voting systems are small, simple polling systems for use in workgroup or personal/home/family settings. They should require almost zero technical skill, be user-friendly, and very simple to setup and maintain.
The functionality which is the end-target of our efforts is a TD voting system which can handle both Occasional/Electoral and Ongoing/Legislative types of voting in the same system. The back-end systems should also be able to handle votes from High-End, Medium-Sized, and Low-End systems concurrently. Additionally, the back-end systems should be able to handle voting traffic from Direct-Democracy, Representative-Democracy, Advisory-Representative-Democracies, and Advisory-Democracies concurrently.
This targeted functionality points to a design which has customized (or customizable) front-end clients and servers, feeding into standardized back-end servers.
Ideally, all TDP systems should be easy to download, setup, configure, use, and monitor. All TDP systems should be usable via the Internet, a LAN, or a WAN -- either with a web-browser or with a separate piece of custom-built client software.
The book "Campaign and Election Reform" written by Glenn H. Utter & Ruth Ann Strickland (c.1997) has some excellent material on problems encountered with both traditional voting systems and newer computerized voting systems. Here is a brief summary of some of the issues brought up in that book.
Open Voting Issues
Open voting is where everyone knows what everyone else voted.
Historically leads to intimidation and violence.
Secret Voting Issues
Stuffing ballot boxes with votes favorable to specific candidates
Destroying ballots for opposition candidates
Falsifying voter registrations
Paying citizens to vote for particular candidates
Falsifying election returns
Election Officials Issues
Defacing ballots cast for opposition candidates
Including favorable, but spoiled, ballots in the ballot count
Substituting pre-marked ballots for real ballots
Incorrectly reporting vote totals
Unlawful Actions Issues
Preventing a qualified citizen from voting
Stuffing ballot boxes
Impersonating a qualified voter
Registering voters illegally
Fraudulently casting absentee ballots
Voting more than once
Other Voting Issues
Some people can't get to the polls when they are only open for a single day, but keeping physical polling places open for multiple days is very expensive and difficult to maintain.
Election forms can be too complicated.
Voters with impairment of vision, mobility, communication, or dexterity have unique challenges which aren't always accounted for.
When mail-in ballots, telephone ballots, paper ballots, and/or computerized ballots are used in combination, there are extra opportunities for error and fraud -- since people could potentially vote with each of the voting methods provided.
Military personal stationed over seas (or on the seas), as well as other expatriates, have unique challenges in casting their votes in local, regional, and national elections.
Gerrymandering -- each political party tries to get voting district lines re-drawn in their favor.
Computerized Voting Issues
Provides "opportunities for vote fraud on a grand scale".
A small group of people can gain access to a computerized voting system and manipulate the outcome of a vote.
Computer operator misconduct
Remote entry into the computerized vote counting process
Inputting of false data
Sabotage for political reasons or otherwise
Traditional Safe Guards Against Fraud
Decentralization of Election Administration
A system of checks where the major political parties monitor each other's electoral behavior
Public accountability made possible by a paper trail
Summary of Voting Issues
Need to insure one-person, one-vote
Need to insure only qualified voters get to vote
Need to insure privacy & anonymity
Need to insure ballots are accurately recorded
Need to insure ballots are accurately counted
Need to insure auditability
Public accountability is key
A more complete treatment of this topic is available by borrowing or purchasing a copy of the "Campaign and Election Reform" book.
Anything that can go wrong with the system or its processes, will go wrong.
This should be expected and prepared for.
Cracking Effort ~ System's Influence
The amount of resources and effort which may, potentially, be brought to bear on cracking or manipulating a TDS will be in direct proportion to how much various people or organizations have to gain or lose by what is being governed by that particular system.
Every Element is Expendable
Any or all versions of any part, component, system, design, configuration, programming language, operating system, crypto key, or crypto algorithm can be compromised at any time, by accident or by skilled & concerted effort.
All Crypto Will Be Broken -- Eventually
With the advent of increasingly more powerful computers and increasingly more sophisticated cryptography techniques, it's just a matter of time before any and all present-day encryption is broken. This should be expected and accounted for when designing and building TDS.
Systems Containing Voter Identities are Potential Threats
Any system containing information that can be traced back to an actual Voter, is a potential threat to Anonymity, Privacy, and Voter Security - even if that information is in encrypted form. Extra care should be taken to minimize the number of systems containing Voter identification information and to secure the information as strongly as is possible.
All Information in any One System, Facility, or Region which is Connectable, will be Connected
This assumes that a System, an entire data center Facility, or an entire Region (state, province, or country) has been compromised and that all the information on the system(s) affected will be pooled and analyzed. And, any information on the affected system(s) which can be connected together, will be connected together. In other words, if a particular Voter's identification, their Voting Preferences, and Actual Votes are all contained in any One System, Facility, or Region, then they are vulnerable to being connected together - even if they are all encrypted with different crypto keys and algorithms.
This, obviously, is a super-paranoid assumption. But, if we can design and build TD systems to handle this assumption without being compromised, then we'd have very secure systems. The one situation which this wouldn't handle is if different Regions cooperated with each other and pooled their resources together. But, the TDS data has to be stored *somewhere*.
The 'cooperating Regions' problem could be addressed in other ways, such as tracking which Regions would be most likely to cooperate with each other & placing them in Meta-Regions. The system could then treat each Meta-Region in the same way it treats individual Regions.
All Voting Data Will Be Stored -- by Someone
This is not to say that official TDP systems will be storing voter information. But, it is to say that, when transmitted over the publicly-accessible Internet, TDS data becomes available to be stored by any person, group, or government which has sufficient access.
In and of itself, this is not a big deal since all the data will be encrypted. However, when combining this idea with the assumption that 'all crypto can be broken', this assumption becomes relevant.
In combination, they point to the possibility that present-day encrypted voting data could be stored -- and then decrypted at a later date, when the data's encryption becomes obsoleted by newer technologies and techniques. Whether that storage period would be 5 years or 50 years is unknowable. But, with the rate of technological innovation these days, it may be a short enough period of time to be a threat to an individual voter's personal security -- if the decrypted voting data were to fall into the wrong hands (such as a corrupt government, corrupt military, or a politically active crime organization).
This, also, is a paranoid assumption. But, if we can build TD systems which can stand up against this sort of breach of privacy, then we'll be doing well.
Earning Peoples' Trust
TDS need to earn the trust of experts & novices alike, as well as the trust of most of the people on the Very-Gullible-to-Super-Paranoid Continuum.
Easy-to-Use, Intuitive, & Metaphor-based
TDS need to be easy-to-use, intuitive, and must use commonly understood metaphors.
Speed of Change ~ Size of Political System
The larger a Political System, the longer it will take to adopt TD technology.
Amount of Positive Potential ~ Size of Political System
The larger the Political System, the more good which can be accomplished by improving that System.
The Best Way to Industrial-Grade Usability
The best way to build Industrial-Grade TDS which the people of the world will trust & will use, is to...
build a best-effort prototype;
run it in parallel with real-life political systems which it could ...
be integrated with, or
continually figure out how it can be improved;
continually fix any problems & evolve the system into a better & more powerful tool, until it is fully ready to be used by real-life political systems;
continue to improve it, even after it is real-life-ready.
The Best Way to TDS Adoption
The best way to get a Techno Democracy Systems (TDS) to be adopted by people is to…
get them to use it in 'parallel' mode;
get them to experience how much more power they have with the TDS than they do with their traditional system;
create a community of people who truly believe in the TDS;
get people to create content for their own organizational, institutional, local, regional, national, and International political systems;
get people to spread the word & get more people involved.
If any piece of the TDS malfunctions for any reason - naturally-caused or human-induced - the rest of the system will continue on unaffected with full integrity.
Every feasible security precaution will be taken.
All production systems will be tested and re-certified on a regular, ongoing basis.
Every security expert in the world will be able to review, study, and openly evaluate all systems, code, procedures, and relationships -- due to the open-source nature of the project.
TDP will try to ensure that no voting system in the world will be more thoroughly reviewed by more experts than TDP's systems.
Privacy, Anonymity, & Personal Safety
Privacy & anonymity will be protected everywhere it is possible.
It is understood that in some parts of the world people's safety will be at risk if their votes are not kept strictly confidential & anonymous. This should be kept in mind as the systems' privacy mechanisms are designed, implemented, & maintained.
The system is to have a standard set of requirements, a standard high-level design, & standard interfaces. But, it is to be implemented with components which will be of different low-level designs, written in different programming languages, and targeted to work on different operating systems.
No voting stream in any given set of 'voting streams' shall be identical in components, configurations, facilities, regions, or groups.
Each 'phase' or 'level' of any given set of 'voting streams' shall consist of no less than 3 different brands of components; which operate on no less than 3 different operating systems; in no less than 3 different facilities; in no less than 3 different regions; and on systems which are controlled by no less than 3 different groups/organizations. We will consider this a 3-path system. A 5-path system is preferable, but will not be feasible until there are enough TDP-certified servers available to accomplish it.
No more than 1/3 of any 'voting stream' or any set of 'voting streams' may use any single brand of component, operating system, facility, region, or group/organization.
Any given component, system, brand, version, operating system, facility, region, or group/organization needs to be expendable & able to be routed around, at any place in the overall system, at any time.
Complete Transparency & Auditability
This Principle is self-explanatory, but is not to be implemented in any way in which would compromise any individual's identity or votes.
TDP should have its own auditing & monitoring groups. But this role should be opened up and made available to other, widely respected, organizations also.
Each voter could be given x number of 'validity checks' for each issue they vote on. These validity checks can then be 'donated' to the voter's choice of vote monitoring organization(s) to use for verifying the integrity of the vote.
Conflict of Interest
Any Conflict of Interest situation, related to any of TDP's voting systems in Development or in Production, should be made public
TDP's systems should be customizable to any language or culture.
TDP's systems should be customizable and/or configurable to fit most/all democracy-based political systems.
TDP's software is to be 100% open-source, so they can be inspected by anyone.
Free or Low Cost
TDP's software is to be Free or Low Cost to anyone and everyone.
TDP's software is to be available world-wide.
Amorphous & Impervious
TDP's implemented network of TD systems is to be amorphous and impervious to complete destruction. Similar to how the Internet was designed in a way which enables it to withstand a nuclear war. Whether it was intentionally designed this way or not has been debated. However, the fact that it has an impossible-to-completely-destroy-without-destroying-most-of-civilization-along-with-it property is not debated. If part of the Internet is destroyed, the rest of it routes around the destroyed section and continues on unaffected. Same idea, but implemented in a world-wide system of voting system servers, etc. and allows for whole sections of TD servers to be excluded for any variety of reasons -- including the servers being destroyed, corrupted, technical problems, International political tensions, etc.
This TDS Principle refers to two different things.
First, for the Source Code, since it will be under an open-source license, it will naturally have the option of being forked -- if that is deemed necessary. This protects everyone's investment into the systems and insures that they will continue on. Rick Moen has written an excellent article on LinuxCare entitled "Fear of Forking". It's currently available here, but may get moved to the archives. It was published on November 17, 1999.
Secondly, for the world-wide network of voting servers, if TDP doesn't sufficiently provide the world with the TD and voting services that are needed, then the individuals and organizations which voluntarily run TD servers in the world-wide TDP network have the option of joining a different TD network. This protects the interest of individuals and democracies world-wide, and allows for TDP to be replaced if it doesn't do a good job.
Build & Use
Part of the TDP process for building a world-class voting system, is to follow a "build & use" strategy. Using TDS Assumption #12 (Industrial-Grade Usability) and TDS Assumption #13 (TDS Adoption) as a base, TDP would build the TD systems. Then, they will be put into production (possibly using one of the Netocracy domain names). This will allow real-world testing of the TD systems, in as close to a real-world TD situation as we can come up with.
Evolutionary Development & Gens
It's not uncommon in software development that after a system is built and in use for some time, that a better design for the system becomes apparent. Also, in the course of starting a new open-source software (OSS) project, it is normal to have only a few people contributing to the project early on. Then, if the project catches on, contributors join the project over time and expand the project's resource pool. TDP can handle both of these phenomena by using an Evolutionary Development approach.
With Evolutionary Development, we can pre-plan each TD system's evolution as a series of Generations of that system -- or Gens for short. Each Gen could tackle a progressively larger and more complex version of the system. By using experience gained from previous Generations of the system, the new Gen could be re-designed, re-shaped, and re-built to be better, faster, more stable, more secure, or whatever.
Each new Gen should be considered a complete re-design and re-build of the system from the ground up -- if that is what's needed to build the best TD system possible. The key is to do whatever it takes to continually be building the best TD systems around. If that means only a minor re-design from one Gen to the next, then so be it. However, if that means a total re-design (like the Mozilla team did with the Netscape browser), then so be it. Initially at least, re-designing and re-building systems from the ground up will be a dauntingly large undertaking. But, over time that should change. Since the overall design of a system will improve over time -- major over-hauls of that system will be increasingly less necessary.
Also, initially, we can plan Generations to be quite focused -- only one platform and one programming language. Then, if resources increase, we could expand out in future Gens to multiple platforms and multiple programming languages.