A government can never truly be open source, at least realistically. There will always be secrets; unpublished code, per say. These secrets are matters of national defense: military operations during a time of declared war, location of the president and vice president so the two are rarely together (for obvious reasons).
However, most of the goings-on of the government should be open. Obama pushes for “open government.” Ron Paul pushes for less government and, presumably, open government, since there would be far less government to hide!
However, open source projects thrive on the involvement of the people. Our current election system does not encourage responsible voting. Take, for example, Pennsylvania’s primary election results. 90,836 PA Republicans voted for Mike Huckabee, who dropped out of the race March 4, 49 days prior to the election. This is like allowing all of the Linux users in PA, regardless of technical knowledge, vote on the addition of one of three kernel features, and giving them only the name of the feature—no description, background, author, codebase, language, performance evaluation, or source! Even more appropriate would be that the developer of the feature conceded that one of the other two features is more efficient and worthwhile than his own!
I’m not saying that only those in-the-know should be allowed the vote. Mistaking my words for that would be fallacious. I believe that every person deserves the right to vote. I believe that every person has the right to have evidence of their vote. I believe that every person has the right to request vote totals for every level of complexity in the elections system: precinct, county, congressional district, state, and federal.
As versatile and open as the Constitution may be—and yes, I believe that it may need some updating to reinforce personal liberty and states’ rights—the government and governance which exists now cannot be patched.
When working on a project, a developer comes to a point where he or she realizes that there is a major defect in the software. He or she (for sake of my fingers, I’m going to use he henceforth, pardon my faux pas) has two options: patch or rewrite. He knows there are serious bugs, bugs which are inherent in the design of the code, as it has been patched since it was written. These most of these patches were good things, but some introduced more bugs which have yet to be fixed.
Should the developer continue to patch the code? Or should he rewrite it, integrating the features of the old version with more manageable code and lessons learned since it was first written?
If he continues to patch it, he treats the problem, but may not actually fix the problem. The problem might be inherent, or the problem may be caused by a combination of other features.
If he rewrites it, he’ll spend a lot of time redoing work he’s already done, but the result will be a more efficient program with fewer bugs (hopefully) and more manageable, cohesive code base. Of course, this new version will have its bugs, too, but they may be easier to find if the code is more manageable.
What the United States needs is a rewrite. The foundations of our government are solid: the Constitution, capitalism and free market economy, liberty for all. These are like the basic functions that make a program tick, “the algorithm,” per say. There are other parts that work, too. However, the maintainers of our government have diverted our attention from the core of the government, preferring us to view the only the parts it wants us to see, i.e. the bling.
The founders—the original authors of the U.S. base code—have long since gone, and they would be disgusted by the mess that is the program and its code base—the federal government—today. Things aren’t going they way that they would have wanted, and there’s a growing part of the population which seeks to return the these ideas, to a set of ideas not much different in theory from the software philosophy of “do one thing and do it well.” The government is bloated, more bloated than any application to which I might possibly compare it.
The founders outlined in the Constitution—a white paper or base algorithm, if you prefer to keep up the programming analogies—the specific functions of the U.S. government. It outlined a process by which the white paper or algorithm itself could be changed to allow more functions or remove functions which endangered the users and their data. However, rather than use this process, the maintainers simply implement functions or remove functions without regard to the users’ opinions, data, or the fact that the users are supporting the maintainers financially.
A fork is nearly impossible. There is no more undiscovered land on the face of the Earth, and it would be difficult for a state to secede. It would be economically infeasible, as well as diplomatically infeasible. The citizens of the new country would have their rights and their government as the Constitution of the U.S.—and of their new country—defines, but they would not have the resources to be self-sufficient, and things imported would cost more.
Fortunately, our government is not setup like the Linux kernel maintenance group in that The President of the United States is not a benevolent dictator (at least not on paper, haha). There are, however, 50 branches of the U.S. kernel which all have their own quirks and maintainers. Like a few projects, perhaps the Debian project included, the U.S. government does have representatives, people who supposedly represent their constituents in the decision-making process having been chosen by those constituents.
The ears of the maintainer are closed. He doesn’t want hear from the users; the people. However, the representatives’ ears are open, and they must be, by definition. In order to change the course of the program; the United States, we, as users; citizens, must elect representatives who believe as we do and not settle for anyone lesser. These representatives will then make the decisions we would make if we were in their position, leading to a program which is more useful, usable, smaller, and most of all, open.
No comments:
Post a Comment