Law in the Internet Society

View   r10  >  r9  >  r8  >  r7  >  r6  >  r5  ...
CrystalMaoFirstPaper 10 - 04 Sep 2012 - Main.IanSullivan
Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="FirstPaper"
>
>
META TOPICPARENT name="FirstPaper2011"
 

Bazaar Expanding : Encouraging Developer Communities in the Developing World

-- CrystalMao - 1 Nov 2011

Line: 27 to 27
 Another strategy is to use trajectories from similar “sister” countries as blueprints for the target country. For example, Kenya’s path towards economic and technology development is both praised and critiqued as a standard-bearing example for its East African neighbors (In this vein, Google’s Nairobi office currently serves as a experience-gathering hub for Google’s eventual expansion into surrounding countries).
Changed:
<
<
Projects should also consider supporting the creation of open technology “hubs” where local technologists can gather to use shared computers, internet access, and collaborate with like minds. Beyond providing tangible tech-enabling resources, countries whose citizens have not converted to living on the internet as the norm can use such centers to foster hacker culture in a physical space, and promote innovation from within the community.
>
>
Projects should also consider supporting the creation of open technology “hubs” where local technologists can gather to use shared computers, internet access, and collaborate with like minds. Beyond providing tangible tech-enabling resources, countries whose citizens have not converted to living on the internet as the norm can use such centers to foster hacker culture in a physical space, and promote innovation from within the community.
 

II. Final thoughts


CrystalMaoFirstPaper 9 - 17 Jan 2012 - Main.CrystalMao
Line: 1 to 1
 
META TOPICPARENT name="FirstPaper"
Deleted:
<
<
 

Bazaar Expanding : Encouraging Developer Communities in the Developing World

-- CrystalMao - 1 Nov 2011

Line: 10 to 9
 While the interconnectivity of our digital economy provides many positive opportunities for the sharing of global expertise, it is also important to recognize and incorporate the role of local, community driven efforts in ushering technological change. This is particularly true as socially conscious developers increasingly tap open source to address developing world needs from afar. Open source (hereafter FLOSS) solutions targeted to developing economies have long been embraced, but many ultimately suffer from lack of a dedicated community of local developers who can support the code long term. See Nah Soo Hoe, Breaking Barriers: The Potential of Free and Open Source Software for Sustainable Human Development, UNDP-ICT4D (2006) (noting the difficulty of building local FLOSS communities as a common theme across projects); See generally FLOSS Survey and Study (2002) 2.7 (finding that nearly 90% of FLOSS developers hail from a handful of western countries / India). This paper explores the unique challenges confronting open source developers in emerging economies, and suggests ways to incentivize developing world production of FLOSS despite these challenges.
Changed:
<
<

I. Unique challenges

Most projects embrace the importance of attracting local developers on paper, but fall through when implementation becomes difficult. Successful mobilization of developing world computer scientists towards FLOSS development requires readjusting our typical understanding of how and why FLOSS communities organize. Eric Raymond has described such communities as gift cultures, within which the “joy of hacking” represents a self-actualization or transcendence that does not kick in until lower level Maslow needs are minimally satisfied:

Gift cultures are adaptations not to scarcity but to abundance. They arise in populations that do not have significant material-scarcity problems with survival goods. . . . It is quite clear that the society of open-source hackers is in fact a gift culture. Within it, there is no serious shortage of the ‘survival necessities’ – disk space, network bandwidth, computing power.

These luxuries are often not enjoyed by computer scientists in the developing world, where shortages in survival goods are common and access to ICT resources and hands on programming skills, even amongst well-educated CS students and professionals, are scarce.

>
>

A. Financial and ICT Resources

 
Changed:
<
<
While the long-run solution undoubtedly hinges on macro factors like economic growth, political stability, and investment in quality education, convincing existing developing world developers to “go FLOSS” requires concerted effort to turn perceived barriers (financial, educational, ICT resource) into incentives for open source development.
>
>
A study of (largely developed world) FLOSS contributors confirmed that open source junkies are, for the most part, not in it for the money, with 70% contributing <10 hours per week and over 65% maintaining full-time employee status at day jobs. Nonetheless, over 50% of contributors received some income from their FLOSS work, and open source companies have the potential to be profitable and sustainable. A “part-time” approach is less feasible in developing economies where many programmers do not have access to computers or the internet outside of school/employment. As mobile devices leapfrog traditional computers to become the dominant computing devices in such societies, FLOSS developers should focus on projects for both the current and the next generation of local mobile platforms (while Symbian is still the dominant OS used in developing countries, Android is positioned for an aggressive push). This helps alleviate the lack of ICT resources that programmers face, and ensures that software products can reach the local community. In regions where the only computing devices programmers have consistent access to are their phones, it would be wise and convenient for these phones to allow for self-programming (perhaps runnng their own SDK and API tools within the operating system). Symbian and Android (let alone iOS) does not allow this without hacks. A second machine should not be necessary for developing world programmers to begin programming the traditional way, by fiddling around. While Symbian, Android, and iOS all provide versatile SDKs for developers once they are on a separate computer, Canonical’s planned Ubuntu mobile OS may be the best bet for fostering a versatile programming environment that requires the least amount of capital investment and confusion.
 
Changed:
<
<

A. Finance

>
>
For experimental programs that are not yet deployed, project founders should also make financial incentives available to at least a core group of local contributors who can then personally recruit and manage the needs of additional local volunteers. Boot-strapped projects may find that their cash goes further in the developing world, and can seek additional funding from programs like Google Summer of Code, project competitions/fellowships, and Kickstarter to support local developers (GSOC summer funding amounts to over 300% of median annual salary in many developing countries). Depending on the target user, local contributors eventually can experiment with selling their code and services.
 
Deleted:
<
<
A study of (largely developed world) FLOSS contributors confirmed that open source junkies are, for the most part, not in it for the money, with 70% contributing <10 hours per week and over 65% maintaining full-time employee status at day jobs. Nonetheless, over 50% of contributors received some income from their FLOSS work, and open source companies have the potential to be profitable and sustainable. A “part-time” approach is not feasible in developing economies where many programmers do not have access to computers or the internet outside of school/employment (conditions obviously vary, but over half my class of senior CS students from Rwanda’s leading technical university did not have computer access at home). Within such environments, project founders should emphasize financial incentives to at least a core group of local contributors who can then personally recruit and manage the needs of additional local volunteers as needed. Boot-strapped projects may find that their cash goes further in the developing world, and can seek additional funding from programs like Google Summer of Code, project competitions/fellowships, and Kickstarter to support local developers (GSOC summer funding amounts to over 300% of median annual salary in many developing countries, in just 3 months). Depending on the target user, local contributors can experiment with selling their code and services.
 

B. Education

Changed:
<
<
Encouraging student developers from local universities is a powerful way to promote FLOSS development in emerging economies. The average CS education in the developing world tends to be heavy on theory, light on practical experience (prior to our class in Rwanda, many of our CS students had never committed a single line of code!). By making an effort to engage and train students, FLOSS projects transform education from a barrier into an incentive. Contributing to FLOSS is rewarding hands-on programming education for beginners, and engages advanced students who out-grow the expertise offered by their local institutions. Pieces of FLOSS projects are also effectively pitched as practical-minded masters or Ph.D. theses that ultimately generate more value and community engagement than the average leather-bound volume of graduate student babble. Projects looking to partner with universities may find it helpful to have an academic on their own team to serve as a credible liaison.

To enhance the mutual value of working with student contributors, existing FLOSS projects can assign less-experienced contributors community mentors, promote formal and informal training (webinars, forums, and an active developer mailing list are crucial), develop standards for documentation/testing/committing, and be cognizant that pieces of the overall project are split into manageable pieces for various skill levels. In-country trainings / meet-ups should emphasize developer education as much as user education. Students in the developing world (perhaps all over the world) seem to be especially fond of obtaining certifications, so any opportunities to create a recognition system to reward skills gained or milestones met should be leveraged.

>
>
Encouraging student developers from local universities is a powerful way to promote FLOSS development in emerging economies. The average CS education in the developing world tends to be heavy on theory, light on practical experience. FLOSS projects that engage and train students transform education from a barrier into an incentive. Contributing to FLOSS is rewarding hands-on programming education for beginners, and engages advanced students who out-grow the expertise offered by their local institutions. Pieces of FLOSS projects are also effectively pitched as practical-minded masters or Ph.D. theses. Projects looking to partner with universities may find it helpful to have an academic on their own team to serve as a credible liaison. To enhance the mutual value of working with student contributors, pieces of the overall project can be split into manageable pieces for various skill levels. In-country trainings / meet-ups should emphasize developer education as much as user education.
 

C. Community

Changed:
<
<
To address the lack of ICT/network resources that developers may face, projects should consider supporting the creation of open technology “hubs” where local technologists can gather to use shared computers, internet access, and collaborate with like minds. Beyond providing tangible tech-enabling resources, countries whose citizens have not converted to living on the internet as the norm can use such centers to foster hacker culture in a physical space, and promote innovation from within the community.
>
>
FLOSS project leaders should take care to avoid using a cookie cutter approach that ignores cultural, historical, and political nuances affecting FLOSS adoption from country to country. For example, projects operating within countries with a dearth of private enterprise and where government contracts dominate technology deployment require different longterm planning than projects in countries with grassroots economies. Community attitudes towards technology and technology education also have a huge impact on the availibility of local programmers (In India, fairly easy to convince average people to learn programming. In the Congo, not so much).
 
Added:
>
>
Despite inevitable culture differences between countries, there are positive, non-culture specific steps that developers can take to encourage FLOSS development. The major way to avoid faux pas in cultural planning is for project leaders to spend extended time on the ground in the countries they are deploying in to familiarize with the local environment. Aligning projects with educational institutions is also a good way to address, or at least identify, cultural obstacles that are unique from country to country. Local academic collaborators tend to be valuable advisors who can shed light on the state of FLOSS development in their communities, including key players and challenges. They can also facilitate legitimacy and community acceptance, characteristics that foreign projects often lack.
 
Changed:
<
<

II. Final thoughts

>
>
Another strategy is to use trajectories from similar “sister” countries as blueprints for the target country. For example, Kenya’s path towards economic and technology development is both praised and critiqued as a standard-bearing example for its East African neighbors (In this vein, Google’s Nairobi office currently serves as a experience-gathering hub for Google’s eventual expansion into surrounding countries).
 
Changed:
<
<
While my discussion in this paper is limited to FLOSS communities in the developing world, but there is ample evidence to suggest that similar principles and benefits apply generally to the generation of information tools (books, directories, academic research, etc.) Truly democratized innovation requires input from all of its users. The culture of the digital economy should not omit creative participation by those with the most to gain from its success.
>
>
Projects should also consider supporting the creation of open technology “hubs” where local technologists can gather to use shared computers, internet access, and collaborate with like minds. Beyond providing tangible tech-enabling resources, countries whose citizens have not converted to living on the internet as the norm can use such centers to foster hacker culture in a physical space, and promote innovation from within the community.
 
Deleted:
<
<
Crystal, I think there are really three issues here: First, whether it is possible for people to make software without computers. Second, whether there are primarily economic obstacles to getting people involved in making free software. Third, whether there are non-economic obstacles, otherwise known as cultural obstacles, to be overcome, and whether those can be stated in non-culture-specific terms.

As to the first, I think we should probably agree that it is difficult if not impossible to make software without computers. The problem is sometimes poverty and limitation of resources, but quite often now, and almost always within a decade, the problem will be not that people have no computers, but rather that the computers they have prohibit programming. Manufacturers all over the world are competing to sell people objects capable of being self-developing systems that are deliberately crippled. They increasingly use OS designs for handsets and tablets that not only aren't self-developing, but enforce memory management models that make programming almost impossible. They provide mobile devices with all sorts of applications, but not terminal programs that would allow programming on remote devices.

If every smartphone and tablet were equipped with a Putty-like combination of SSH and Xterm, not only would everyone have access to more secure, more private, proxy-based browsing that leapt national firewalls, they would also have a tool which (with shell access somewhere else) would allow remote programming activity that would lead directly to FOSS participation.

One of the primary reasons Richard and I put such emphasis on the "installation information for user devices" component of section 6 of GPLv3 was to discourage as far as we could with the weight of GPL'd software the creation of hackable consumer electronics, so that people in the world who can only afford one digital computer (such as a mobile phone) would get the chance to become effective and useful programmers. You don't mention anywhere here how the greed-structured nature of capitalist technology is creating this part of the problem you are concerned with, nor do you mention anywhere a reason not to believe that the hardest part of the hardest problem is, as usual, best exemplified by the dead anti-hero Steven P. Jobs.

(I must say that I take your Rwandan story very differently than you do. When in Rwanda half of the students in even the most privileged educational institutions have access to computers at home, you know how far the process of putting computers and the Net everywhere has gone. In what year did that become true of the US?)

On the second point, I do not think that the question is how people who make free software would make money. The global IT giants alone, let alone all the commercial, industrial and financial enterprises they serve, could absorb several hundred thousand more free software makers immediately. Labor market constraints that inhibit globalization of many kinds of valuable activity have little effect on collaborative software effort, and programming (unlike many kinds of network-connected service business activity) does not require high-bandwidth infrastructure. In any capital city in the world, including in Africa, if you had a collective of a dozen or more free software programmers with proven skills, you could get them hired to perform project work at prices that would be lavish by almost all local-society standards. Soon, that is with ten years, the labor exchanges necessary to make that work simpler to get, including the reputational capital systems necessary to allow programmers working in arbitrary places to demonstrate their track record as free software contributors to potential employers, will have come into existence, and the barrier to individual free software entrepreneurialism will be quite low.

Third, well, there's third. Your essay presents no analysis of cultural obstacles, because it doesn't acknowledge the existence of cultural obstacles because it has nothing to say about culture. I think, as I've already indicated, that this is a mistake. In my slight experience with free software and its adoption around the world, I've seen societies and states behave very differently from one another, but very explicably in historical and cultural terms. This is true also, I think, at lower levels of demographic granularity.

 
Changed:
<
<
>
>

II. Final thoughts

 
Added:
>
>
While my discussion in this paper is limited to FLOSS communities in the developing world, but there is ample evidence to suggest that similar principles and benefits apply generally to the generation of information tools and collaborative content. Truly democratized innovation requires input from all of its users. The culture of the digital economy should not omit creative participation by those with the most to gain from its success.
 
You are entitled to restrict access to your paper if you want to. But we all derive immense benefit from reading one another's work, and I hope you won't feel the need unless the subject matter is personal and its disclosure would be harmful or undesirable.

CrystalMaoFirstPaper 8 - 07 Dec 2011 - Main.EbenMoglen
Line: 1 to 1
 
META TOPICPARENT name="FirstPaper"
Deleted:
<
<
Re-edited for length.
 

Bazaar Expanding : Encouraging Developer Communities in the Developing World

Line: 40 to 38
 While my discussion in this paper is limited to FLOSS communities in the developing world, but there is ample evidence to suggest that similar principles and benefits apply generally to the generation of information tools (books, directories, academic research, etc.) Truly democratized innovation requires input from all of its users. The culture of the digital economy should not omit creative participation by those with the most to gain from its success.
Added:
>
>
Crystal, I think there are really three issues here: First, whether it is possible for people to make software without computers. Second, whether there are primarily economic obstacles to getting people involved in making free software. Third, whether there are non-economic obstacles, otherwise known as cultural obstacles, to be overcome, and whether those can be stated in non-culture-specific terms.

As to the first, I think we should probably agree that it is difficult if not impossible to make software without computers. The problem is sometimes poverty and limitation of resources, but quite often now, and almost always within a decade, the problem will be not that people have no computers, but rather that the computers they have prohibit programming. Manufacturers all over the world are competing to sell people objects capable of being self-developing systems that are deliberately crippled. They increasingly use OS designs for handsets and tablets that not only aren't self-developing, but enforce memory management models that make programming almost impossible. They provide mobile devices with all sorts of applications, but not terminal programs that would allow programming on remote devices.

If every smartphone and tablet were equipped with a Putty-like combination of SSH and Xterm, not only would everyone have access to more secure, more private, proxy-based browsing that leapt national firewalls, they would also have a tool which (with shell access somewhere else) would allow remote programming activity that would lead directly to FOSS participation.

One of the primary reasons Richard and I put such emphasis on the "installation information for user devices" component of section 6 of GPLv3 was to discourage as far as we could with the weight of GPL'd software the creation of hackable consumer electronics, so that people in the world who can only afford one digital computer (such as a mobile phone) would get the chance to become effective and useful programmers. You don't mention anywhere here how the greed-structured nature of capitalist technology is creating this part of the problem you are concerned with, nor do you mention anywhere a reason not to believe that the hardest part of the hardest problem is, as usual, best exemplified by the dead anti-hero Steven P. Jobs.

(I must say that I take your Rwandan story very differently than you do. When in Rwanda half of the students in even the most privileged educational institutions have access to computers at home, you know how far the process of putting computers and the Net everywhere has gone. In what year did that become true of the US?)

On the second point, I do not think that the question is how people who make free software would make money. The global IT giants alone, let alone all the commercial, industrial and financial enterprises they serve, could absorb several hundred thousand more free software makers immediately. Labor market constraints that inhibit globalization of many kinds of valuable activity have little effect on collaborative software effort, and programming (unlike many kinds of network-connected service business activity) does not require high-bandwidth infrastructure. In any capital city in the world, including in Africa, if you had a collective of a dozen or more free software programmers with proven skills, you could get them hired to perform project work at prices that would be lavish by almost all local-society standards. Soon, that is with ten years, the labor exchanges necessary to make that work simpler to get, including the reputational capital systems necessary to allow programmers working in arbitrary places to demonstrate their track record as free software contributors to potential employers, will have come into existence, and the barrier to individual free software entrepreneurialism will be quite low.

Third, well, there's third. Your essay presents no analysis of cultural obstacles, because it doesn't acknowledge the existence of cultural obstacles because it has nothing to say about culture. I think, as I've already indicated, that this is a mistake. In my slight experience with free software and its adoption around the world, I've seen societies and states behave very differently from one another, but very explicably in historical and cultural terms. This is true also, I think, at lower levels of demographic granularity.

 
You are entitled to restrict access to your paper if you want to. But we all derive immense benefit from reading one another's work, and I hope you won't feel the need unless the subject matter is personal and its disclosure would be harmful or undesirable.

CrystalMaoFirstPaper 7 - 10 Nov 2011 - Main.CrystalMao
Line: 1 to 1
 
META TOPICPARENT name="FirstPaper"
Changed:
<
<
(this is ready for edits/comments, but also excessively wordy . . so I will be cutting it down. perhaps you can all be ruthless in helping me do that. but first i must sleep.)
>
>
Re-edited for length.
 
Deleted:
<
<
A week has gone by, and I assume you've slept, but the piece is still 40% overlength. There's no point having length limits if they're going to be so heavily busted. Bring it down to 1,000 words, Crystal, please, and I'll be happy to read the draft right away.
 

Bazaar Expanding : Encouraging Developer Communities in the Developing World

Line: 11 to 10
 
Changed:
<
<
While the interconnectivity of our digital economy provides many positive opportunities for the sharing of global expertise, it is also important to recognize and incorporate the role of local, community driven efforts in ushering technological change. This is particularly true as socially conscious developers increasingly tap open source to address developing world needs from afar. Open source (hereafter FLOSS) solutions targeted to developing economies have long been embraced, but many ultimately suffer from lack of a dedicated community of local developers who can support the code long term. See Nah Soo Hoe, Breaking Barriers: The Potential of Free and Open Source Software for Sustainable Human Development, UNDP-ICT4D (2006) (noting the difficulty of building local FLOSS communities as a common theme across projects); See generally FLOSS Survey and Study (2002) 2.7 (finding that nearly 90% of FLOSS developers hail from a handful of western countries / India). This paper begins by summarizing the importance for project founders to originate from or otherwise establish a local base of developer support. It then explores the unique challenges confronting open source developers in emerging economies, and concludes with ways to incentivize developing world production of FLOSS despite these challenges.
>
>
While the interconnectivity of our digital economy provides many positive opportunities for the sharing of global expertise, it is also important to recognize and incorporate the role of local, community driven efforts in ushering technological change. This is particularly true as socially conscious developers increasingly tap open source to address developing world needs from afar. Open source (hereafter FLOSS) solutions targeted to developing economies have long been embraced, but many ultimately suffer from lack of a dedicated community of local developers who can support the code long term. See Nah Soo Hoe, Breaking Barriers: The Potential of Free and Open Source Software for Sustainable Human Development, UNDP-ICT4D (2006) (noting the difficulty of building local FLOSS communities as a common theme across projects); See generally FLOSS Survey and Study (2002) 2.7 (finding that nearly 90% of FLOSS developers hail from a handful of western countries / India). This paper explores the unique challenges confronting open source developers in emerging economies, and suggests ways to incentivize developing world production of FLOSS despite these challenges.
 
Changed:
<
<

I. The Importance of Local Talent

>
>

I. Unique challenges

 
Changed:
<
<
Development for the people, by the people means better functionality for the end-user. Software that originates in first-world countries often reflects first-world needs and biases that are not well-suited for users in the developing world. Over a year into international deployments of Sana Mobile, my friend and co-developer wrote, after teaching a training workshop in India:

It seems the biggest problem we will face in this pilot is language. Some of the health workers in Raichur may not be literate at all in either Kannada, the local script, or English. This is a big problem if we are trying to get them to fill out forms on our phones.

It was an obvious problem with a simple solution, but throughout months of frenzied development of fancier and more exciting features from Cambridge, we had completely overlooked something that a local developer spotted in less than an hour.

Development for the people, by the people also improves sustainability. A locally tended code is more likely to survive everything from sudden server crashes to evolving features needs because developers who are close (and in the same time zone) to the community are more responsive to things like maintenance, upkeep, user error and need. Would you rather hire the plumber next door, or one you have to call on Skype to show you how to fix the toilet remotely? Local developers can charge for these services, and projects will still realize financial savings: hiring local developers for support requires lower costs of labor, which decreases total cost of ownership.

There are certainly other positives to explore, such as resulting skills development and an improved sense of community ownership (“every good work of software starts by scratching a developer’s personal itch”) over technology-based solutions, which can reduce brain drain and wariness towards westerners coming in with gadgets and gizmos . . . but I’m already getting too wordy so let’s leave those rocks prodded but unturned.

II. Unique challenges

Most projects embrace the importance of attracting local developers on paper, but fall through when implementation becomes difficult: relationships with local partners sour, language barriers abound, it’s just easier to code the thing yourself. Successful mobilization of developing world computer scientists towards FLOSS development requires readjusting the our typical understanding of how and why FLOSS communities organize. Eric Raymond has described such communities as gift cultures, within which the “joy of hacking” represents a self-actualization or transcendence that does not kick in until lower level Maslow needs are minimally satisfied:

>
>
Most projects embrace the importance of attracting local developers on paper, but fall through when implementation becomes difficult. Successful mobilization of developing world computer scientists towards FLOSS development requires readjusting our typical understanding of how and why FLOSS communities organize. Eric Raymond has described such communities as gift cultures, within which the “joy of hacking” represents a self-actualization or transcendence that does not kick in until lower level Maslow needs are minimally satisfied:
 
Gift cultures are adaptations not to scarcity but to abundance. They arise in populations that do not have significant material-scarcity problems with survival goods. . . . It is quite clear that the society of open-source hackers is in fact a gift culture. Within it, there is no serious shortage of the ‘survival necessities’ – disk space, network bandwidth, computing power.
Changed:
<
<
These abundances are often not enjoyed by computer scientists in the developing world, where shortages in survival goods are common and access to ICT resources and hands on programming skills, even amongst well-educated CS students and professionals, are scarce. See IDI Development Index (2009) (detailing the lack of access to reliable ICT systems in the developing world, particularly amongst African nations).
>
>
These luxuries are often not enjoyed by computer scientists in the developing world, where shortages in survival goods are common and access to ICT resources and hands on programming skills, even amongst well-educated CS students and professionals, are scarce.
 
Changed:
<
<
While the long-run solution undoubtedly hinges on macro factors like economic growth, political stability, and investment in quality education, convincing existing developing world developers to “go FLOSS” requires concerted effort from both domestic and international communities to turn perceived barriers (financial, educational, ICT resource) into incentives for open source development.
>
>
While the long-run solution undoubtedly hinges on macro factors like economic growth, political stability, and investment in quality education, convincing existing developing world developers to “go FLOSS” requires concerted effort to turn perceived barriers (financial, educational, ICT resource) into incentives for open source development.
 

A. Finance

Changed:
<
<
A comprehensive study of (largely developed world) FLOSS contributors confirmed that open source junkies are, for the most part, not in it for the money, with 70% contributing <10 hours per week and over 65% maintaining full-time employee status at day jobs. Nonetheless, over 50% of contributors received some income from their FLOSS work, and open source companies have the potential to be profitable and sustainable. A “part-time” approach is not feasible in developing economies where many programmers do not have access to computers or the internet outside of school/employment (conditions obviously vary, but over half my class of senior CS students from Rwanda’s leading technical university did not have computer access at home). Working within such environments, project founders should structure financial incentives to at least a core group of local contributors who can then personally recruit and manage the needs of additional local volunteers as needed. Boot-strapped projects may find that their cash goes further in the developing world, and can seek additional funding from programs like Google Summer of Code, project competitions/fellowships, and Kickstarter to support local developers (GSOC summer funding amounts to over 300% of median annual salary in many developing countries, in just 3 months). Depending on the target user, local contributors can experiment with selling their code and services –ultimately, projects need to aggressively iterate and launch with local customers, and this can also be a good way to expand distribution.
>
>
A study of (largely developed world) FLOSS contributors confirmed that open source junkies are, for the most part, not in it for the money, with 70% contributing <10 hours per week and over 65% maintaining full-time employee status at day jobs. Nonetheless, over 50% of contributors received some income from their FLOSS work, and open source companies have the potential to be profitable and sustainable. A “part-time” approach is not feasible in developing economies where many programmers do not have access to computers or the internet outside of school/employment (conditions obviously vary, but over half my class of senior CS students from Rwanda’s leading technical university did not have computer access at home). Within such environments, project founders should emphasize financial incentives to at least a core group of local contributors who can then personally recruit and manage the needs of additional local volunteers as needed. Boot-strapped projects may find that their cash goes further in the developing world, and can seek additional funding from programs like Google Summer of Code, project competitions/fellowships, and Kickstarter to support local developers (GSOC summer funding amounts to over 300% of median annual salary in many developing countries, in just 3 months). Depending on the target user, local contributors can experiment with selling their code and services.
 

B. Education

Changed:
<
<
Encouraging student developers from local universities is a powerful way to promote FLOSS development in emerging economies. The average CS education in the developing world tends to be heavy on theory, light on practical experience (prior to our class in Rwanda, many of our CS students had never committed a single line of code!). By making an effort to engage and train students, FLOSS projects transform education from a barrier into an incentive. Contributing to open-source initiatives is rewarding hands-on programming education for beginners, and engages advanced students who out-grow the expertise offered by their local institutions. Pieces of FLOSS projects are also effectively pitched as practical-minded masters or Ph.D. theses that ultimately generate more value and community engagement than the average leather-bound volume of graduate student babble. Projects looking to partner with universities may find it helpful to have an academic on their own team to serve as a credible liaison. To enhance the mutual value of working with student contributors, existing FLOSS projects can assign less-experienced contributors community mentors, promote formal and informal training (webinars, forums, and an active developer mailing list are crucial), develop standards for documentation/testing/committing, and be cognizant that pieces of the overall project are split into manageable pieces for various skill levels. In-country trainings / meet-ups should be focused on both developer and user education. Students in the developing world (perhaps all over the world) seem to be especially fond of obtaining certifications, so any opportunities to create a recognition system in lockstep with skills gained or milestones met should be leveraged.
>
>
Encouraging student developers from local universities is a powerful way to promote FLOSS development in emerging economies. The average CS education in the developing world tends to be heavy on theory, light on practical experience (prior to our class in Rwanda, many of our CS students had never committed a single line of code!). By making an effort to engage and train students, FLOSS projects transform education from a barrier into an incentive. Contributing to FLOSS is rewarding hands-on programming education for beginners, and engages advanced students who out-grow the expertise offered by their local institutions. Pieces of FLOSS projects are also effectively pitched as practical-minded masters or Ph.D. theses that ultimately generate more value and community engagement than the average leather-bound volume of graduate student babble. Projects looking to partner with universities may find it helpful to have an academic on their own team to serve as a credible liaison.

To enhance the mutual value of working with student contributors, existing FLOSS projects can assign less-experienced contributors community mentors, promote formal and informal training (webinars, forums, and an active developer mailing list are crucial), develop standards for documentation/testing/committing, and be cognizant that pieces of the overall project are split into manageable pieces for various skill levels. In-country trainings / meet-ups should emphasize developer education as much as user education. Students in the developing world (perhaps all over the world) seem to be especially fond of obtaining certifications, so any opportunities to create a recognition system to reward skills gained or milestones met should be leveraged.

 

C. Community

Changed:
<
<
To address the lack of ICT/network resources that developers may face, projects, communities, and donors should consider supporting the creation of open technology “hubs” where local technologists can gather to use shared computers, internet access, and collaborate with like minds. Beyond providing tangible tech-enabling resources, countries whose citizens have not converted to living on the internet as the norm can use such centers to foster hacker culture in a physical space, and promote innovation from within the community.
>
>
To address the lack of ICT/network resources that developers may face, projects should consider supporting the creation of open technology “hubs” where local technologists can gather to use shared computers, internet access, and collaborate with like minds. Beyond providing tangible tech-enabling resources, countries whose citizens have not converted to living on the internet as the norm can use such centers to foster hacker culture in a physical space, and promote innovation from within the community.
 
Changed:
<
<

III. Final thoughts

>
>

II. Final thoughts

 
Changed:
<
<
Time, space, and personal experience have limited my discussion in this paper to FLOSS communities in the developing world, but there is ample evidence to suggest that similar principles and benefits apply to the generation of information tools more generally (books, directories, academic research, etc.) Truly democratized innovation requires input from all of its users. The culture of the digital economy should not omit creative participation by those with the most to gain from its success.
>
>
While my discussion in this paper is limited to FLOSS communities in the developing world, but there is ample evidence to suggest that similar principles and benefits apply generally to the generation of information tools (books, directories, academic research, etc.) Truly democratized innovation requires input from all of its users. The culture of the digital economy should not omit creative participation by those with the most to gain from its success.
 



CrystalMaoFirstPaper 6 - 07 Nov 2011 - Main.EbenMoglen
Line: 1 to 1
 
META TOPICPARENT name="FirstPaper"
(this is ready for edits/comments, but also excessively wordy . . so I will be cutting it down. perhaps you can all be ruthless in helping me do that. but first i must sleep.)
Added:
>
>
A week has gone by, and I assume you've slept, but the piece is still 40% overlength. There's no point having length limits if they're going to be so heavily busted. Bring it down to 1,000 words, Crystal, please, and I'll be happy to read the draft right away.
 

Bazaar Expanding : Encouraging Developer Communities in the Developing World

-- CrystalMao - 1 Nov 2011


CrystalMaoFirstPaper 5 - 01 Nov 2011 - Main.CrystalMao
Line: 1 to 1
 
META TOPICPARENT name="FirstPaper"
Changed:
<
<

Potential Topic: Freemium Open Access

>
>
(this is ready for edits/comments, but also excessively wordy . . so I will be cutting it down. perhaps you can all be ruthless in helping me do that. but first i must sleep.)
 
Changed:
<
<
[1] Intro: One of the fundamental rationales underlying the need for open access of zero-marginal cost goods is that it's in the interest of justice
>
>

Bazaar Expanding : Encouraging Developer Communities in the Developing World

 
Changed:
<
<
[2] Question: But does justice demand that the experience of accessing the information be equal? Does open access = equal access?
>
>
-- CrystalMao - 1 Nov 2011
 
Changed:
<
<
[3a] Illustrative Examples:
  • Reading Shakespeare for free as a text file online, v. buying a leather bound edition for $30
  • Boston.com (Trashy) v. Typographer's-dream (Bostonglobe.com): SAME content, vastly different experiences.
  • MIT OCW v. attending MIT
  • Downloading the source code and self-installing v. Paying a consultant to install and configure

[3b] NOT freemium:

  • NYT paywall, 30-day software trials, etc.
  • Difference here is that the "premium" versions of these services offer content and/or access that is not available to non-paying users. In my contemplated system, the access to the fundamental content should be the same.

[4] Proposal: Perhaps a good way to make core information available to everyone, yet preserve free-market esque revenue streams that can

  1. fund the costs and incentivize the efforts of further development,
  2. incentivize people/users towards upward mobility
  3. add more thoughts here,
is to encourage a tiered system that requires people to give away the core information for free, but allows them to charge for the bells & whistles

[5] Problems

  • Is this a sustainable model for key industries - music, movies, where 90% of the value is just the file itself? (Former Rep. Bob Ingles said in a talk I went to last week - "Sustainability means profit")
    • Is it possible to maintain systems where the "premium" version doesn't = premium access to content? At which point do services become or = content?
    • How would this work for software, particularly expensive software like Adobe?
  • Does this address the justice problem? Just because people have access to information doesn't mean that it's in a form that facilitates them to use it.
  • What is the ideal equilibrium-society that I am trying to promote? (think about this)
>
>
 
Changed:
<
<
-- By CrystalMao - 14 Oct 2011
>
>
While the interconnectivity of our digital economy provides many positive opportunities for the sharing of global expertise, it is also important to recognize and incorporate the role of local, community driven efforts in ushering technological change. This is particularly true as socially conscious developers increasingly tap open source to address developing world needs from afar. Open source (hereafter FLOSS) solutions targeted to developing economies have long been embraced, but many ultimately suffer from lack of a dedicated community of local developers who can support the code long term. See Nah Soo Hoe, Breaking Barriers: The Potential of Free and Open Source Software for Sustainable Human Development, UNDP-ICT4D (2006) (noting the difficulty of building local FLOSS communities as a common theme across projects); See generally FLOSS Survey and Study (2002) 2.7 (finding that nearly 90% of FLOSS developers hail from a handful of western countries / India). This paper begins by summarizing the importance for project founders to originate from or otherwise establish a local base of developer support. It then explores the unique challenges confronting open source developers in emerging economies, and concludes with ways to incentivize developing world production of FLOSS despite these challenges.
 
Changed:
<
<
In assessing my examples, perhaps I need to distinguish between a "premium" version that has been transformed into a MC / 0 product (e.g., an MIT education, a physical book) , vs. premium versions that are still MC = 0 (Bostonglobe.com with improved layout and no ads). Does this distinction matter? Is it unethical to restrict access for premium versions that are MC=0, even if the underlying content is available for free?
>
>

I. The Importance of Local Talent

 
Changed:
<
<
--By CrystalMao - 18 Oct 2011
>
>
Development for the people, by the people means better functionality for the end-user. Software that originates in first-world countries often reflects first-world needs and biases that are not well-suited for users in the developing world. Over a year into international deployments of Sana Mobile, my friend and co-developer wrote, after teaching a training workshop in India:
 
Added:
>
>
It seems the biggest problem we will face in this pilot is language. Some of the health workers in Raichur may not be literate at all in either Kannada, the local script, or English. This is a big problem if we are trying to get them to fill out forms on our phones.
 
Added:
>
>
It was an obvious problem with a simple solution, but throughout months of frenzied development of fancier and more exciting features from Cambridge, we had completely overlooked something that a local developer spotted in less than an hour.
 
Added:
>
>
Development for the people, by the people also improves sustainability. A locally tended code is more likely to survive everything from sudden server crashes to evolving features needs because developers who are close (and in the same time zone) to the community are more responsive to things like maintenance, upkeep, user error and need. Would you rather hire the plumber next door, or one you have to call on Skype to show you how to fix the toilet remotely? Local developers can charge for these services, and projects will still realize financial savings: hiring local developers for support requires lower costs of labor, which decreases total cost of ownership.
 
Changed:
<
<
It is strongly recommended that you include your outline in the body of your essay by using the outline as section titles. The headings below are there to remind you how section and subsection titles are formatted.
>
>
There are certainly other positives to explore, such as resulting skills development and an improved sense of community ownership (“every good work of software starts by scratching a developer’s personal itch”) over technology-based solutions, which can reduce brain drain and wariness towards westerners coming in with gadgets and gizmos . . . but I’m already getting too wordy so let’s leave those rocks prodded but unturned.
 
Changed:
<
<

Section I

>
>

II. Unique challenges

 
Changed:
<
<

Subsection A

>
>
Most projects embrace the importance of attracting local developers on paper, but fall through when implementation becomes difficult: relationships with local partners sour, language barriers abound, it’s just easier to code the thing yourself. Successful mobilization of developing world computer scientists towards FLOSS development requires readjusting the our typical understanding of how and why FLOSS communities organize. Eric Raymond has described such communities as gift cultures, within which the “joy of hacking” represents a self-actualization or transcendence that does not kick in until lower level Maslow needs are minimally satisfied:
 
Added:
>
>
Gift cultures are adaptations not to scarcity but to abundance. They arise in populations that do not have significant material-scarcity problems with survival goods. . . . It is quite clear that the society of open-source hackers is in fact a gift culture. Within it, there is no serious shortage of the ‘survival necessities’ – disk space, network bandwidth, computing power.
 
Changed:
<
<

Subsub 1

>
>
These abundances are often not enjoyed by computer scientists in the developing world, where shortages in survival goods are common and access to ICT resources and hands on programming skills, even amongst well-educated CS students and professionals, are scarce. See IDI Development Index (2009) (detailing the lack of access to reliable ICT systems in the developing world, particularly amongst African nations).
 
Changed:
<
<

Subsection B

>
>
While the long-run solution undoubtedly hinges on macro factors like economic growth, political stability, and investment in quality education, convincing existing developing world developers to “go FLOSS” requires concerted effort from both domestic and international communities to turn perceived barriers (financial, educational, ICT resource) into incentives for open source development.
 
Added:
>
>

A. Finance

 
Changed:
<
<

Subsub 1

>
>
A comprehensive study of (largely developed world) FLOSS contributors confirmed that open source junkies are, for the most part, not in it for the money, with 70% contributing <10 hours per week and over 65% maintaining full-time employee status at day jobs. Nonetheless, over 50% of contributors received some income from their FLOSS work, and open source companies have the potential to be profitable and sustainable. A “part-time” approach is not feasible in developing economies where many programmers do not have access to computers or the internet outside of school/employment (conditions obviously vary, but over half my class of senior CS students from Rwanda’s leading technical university did not have computer access at home). Working within such environments, project founders should structure financial incentives to at least a core group of local contributors who can then personally recruit and manage the needs of additional local volunteers as needed. Boot-strapped projects may find that their cash goes further in the developing world, and can seek additional funding from programs like Google Summer of Code, project competitions/fellowships, and Kickstarter to support local developers (GSOC summer funding amounts to over 300% of median annual salary in many developing countries, in just 3 months). Depending on the target user, local contributors can experiment with selling their code and services –ultimately, projects need to aggressively iterate and launch with local customers, and this can also be a good way to expand distribution.
 
Added:
>
>

B. Education

 
Changed:
<
<

Subsub 2

>
>
Encouraging student developers from local universities is a powerful way to promote FLOSS development in emerging economies. The average CS education in the developing world tends to be heavy on theory, light on practical experience (prior to our class in Rwanda, many of our CS students had never committed a single line of code!). By making an effort to engage and train students, FLOSS projects transform education from a barrier into an incentive. Contributing to open-source initiatives is rewarding hands-on programming education for beginners, and engages advanced students who out-grow the expertise offered by their local institutions. Pieces of FLOSS projects are also effectively pitched as practical-minded masters or Ph.D. theses that ultimately generate more value and community engagement than the average leather-bound volume of graduate student babble. Projects looking to partner with universities may find it helpful to have an academic on their own team to serve as a credible liaison. To enhance the mutual value of working with student contributors, existing FLOSS projects can assign less-experienced contributors community mentors, promote formal and informal training (webinars, forums, and an active developer mailing list are crucial), develop standards for documentation/testing/committing, and be cognizant that pieces of the overall project are split into manageable pieces for various skill levels. In-country trainings / meet-ups should be focused on both developer and user education. Students in the developing world (perhaps all over the world) seem to be especially fond of obtaining certifications, so any opportunities to create a recognition system in lockstep with skills gained or milestones met should be leveraged.
 
Added:
>
>

C. Community

 
Added:
>
>
To address the lack of ICT/network resources that developers may face, projects, communities, and donors should consider supporting the creation of open technology “hubs” where local technologists can gather to use shared computers, internet access, and collaborate with like minds. Beyond providing tangible tech-enabling resources, countries whose citizens have not converted to living on the internet as the norm can use such centers to foster hacker culture in a physical space, and promote innovation from within the community.
 
Deleted:
<
<

Section II

 
Changed:
<
<

Subsection A

>
>

III. Final thoughts

 
Changed:
<
<

Subsection B

>
>
Time, space, and personal experience have limited my discussion in this paper to FLOSS communities in the developing world, but there is ample evidence to suggest that similar principles and benefits apply to the generation of information tools more generally (books, directories, academic research, etc.) Truly democratized innovation requires input from all of its users. The culture of the digital economy should not omit creative participation by those with the most to gain from its success.
 


Line: 91 to 76
 However, the 'accompanying services' model has worked well for many free software companies, eg, RedHat? , Ubuntu, etc. The concept of "accompanying services" can also be extended, as Austin suggests, to include customizations - charging customers for special customizations of material. However, while this applies to software, it is difficult to see how it would apply to books and music.

-- DevinMcDougall - 19 Oct 2011 \ No newline at end of file

Added:
>
>

Austin + Devin, thanks for your thoughtful comments. As you can see I've decided to scrap my initial idea to write about something nearer-and-dearer to my heart and work (Devin, you're right that I'm not really a fan of normative thinking and much prefer empiricism / case study type analysis).

But! I stand behind my original idea . . defining core vs. non-core could come down to a distinction between the information itself vs. things that enhance or detracts from use / enjoyment of that information. Content-holders can generate positive non-core (for software: service contracts, custom code development, for media: enhanced layouts, better HD/bitrates quality for movies/music) or negative non-core (ads) complements to try and extract some kind of revenue stream. Core vs. non-core can also change depending on the type of good, the degree of segmentation preferred, and current market climate. In general I think that segmentation is a good compromise: an ebook on .txt versus one that has been beautifully laid out, with thought to typeface and perfect kerning do have different market values (to typography lovers, at least). As long as the essential ideas are available without restriction, people should be able to profit off of providing enhanced enjoyment. But yeah, there would need to be a good business case (increased user base?) for rights-holders to release basic content in the first place. . . the NYT / Hulu have headed other way, so perhaps that is not a good sign.

-- CrystalMao - 1 Nov 2011

META FILEATTACHMENT attachment="RANTISI_-_innovation_communities.pdf" attr="" comment="" date="1320131417" name="RANTISI_-_innovation_communities.pdf" path="RANTISI - innovation_communities.pdf" size="1028956" stream="RANTISI - innovation_communities.pdf" user="Main.CrystalMao" version="1"

CrystalMaoFirstPaper 4 - 19 Oct 2011 - Main.DevinMcDougall
Line: 1 to 1
 
META TOPICPARENT name="FirstPaper"

Potential Topic: Freemium Open Access

Line: 85 to 85
 

-- AustinKlar -- Oct 19 2011 \ No newline at end of file

Added:
>
>
. I just wanted to chime in to note that if you want to frame your paper around the question of what justice requires, you will probably need to develop an account of what justice is. That will be a fairly serious undertaking. It seems like most of the material you've got here is less about normative questions, and more about the business side of things, the empirical question of "what works" rather than normative question of "what justice requires." Rather than asking if justice will allow or disallow companies monetizing content through advertising, you might want to narrow down to the question of: does an advertising or other premium type thing work as a business model to a) generate profit and b) actually increase access to content. One potential issue there is the question of how much longer content-embedded advertising will exist as a business opportunity. Bitstreams are easy to filter, as the folks at AdBlock? have demonstrated. This is not good for people who want to make money off inserting things people don't want into their bitstreams.

However, the 'accompanying services' model has worked well for many free software companies, eg, RedHat? , Ubuntu, etc. The concept of "accompanying services" can also be extended, as Austin suggests, to include customizations - charging customers for special customizations of material. However, while this applies to software, it is difficult to see how it would apply to books and music.

-- DevinMcDougall - 19 Oct 2011

 \ No newline at end of file

CrystalMaoFirstPaper 3 - 19 Oct 2011 - Main.AustinKlar
Line: 1 to 1
 
META TOPICPARENT name="FirstPaper"

Potential Topic: Freemium Open Access

Line: 73 to 73
 # * Set ALLOWTOPICVIEW = TWikiAdminGroup, CrystalMao

Note: TWiki has strict formatting rules. Make sure you preserve the three spaces, asterisk, and extra space at the beginning of that line. If you wish to give access to any other users simply add them to the comma separated list \ No newline at end of file

Added:
>
>

Comment:

First, I think a system that requires "core" information to be given freely but allowing creators to charge for "bells & whistles" could work in theory. But, the problem with implementing a system like this might be defining core vs. not core. With free software, seemingly no money is derived from distributing the product itself - its free. But, my understanding is that, as you noted, a lot of companies charge for perhaps consulting on how to use the software, and how to set up the software. Free software, as you mentioned in class, is not readily usable by people who aren't technologically savvy and thus need others to help them learn. Many companies charge for these services. But shouldn't that service be considered part of the core or not part of the core. Free software is only good if you are able to use it so it is essential for many that they get that service. Thus it could be deemed "core." But, its technically not the software itself but rather what you might consider a premium (something on top of the core software). So, if this system is to work, there needs to be a good way of defining what is core vs. not core. I think you thought about this when you said "at which point do services become or equal content."

Further, if people are only going to make money by charging for bells and whistles, might not this lead to a system in which people derogate from the core and make content part of the non-core (by whatever method) in order to make more money? What in the system will prevent them from doing this?

I think that this system can work - if what's important to us is getting as much information to as many people as possible, for the lowest cost possible, then the core information really is what matters. If people want premium, they can pay for it. But the fact that something is a premium means it is extra, it is on top of the core information we truly care about. So even if we charge for the premium, even its MC=0, i don't think that's an injustice. If people want extra, they can pay for it. Since its extra, there is less demand for it and the price might go down to close to 0 or even 0 in some circumstances. The system you are proposing really relies on the definition of core vs. not core, and how we are to prevent creators from abusing these definitions to maximize profit.

-- AustinKlar -- Oct 19 2011

 \ No newline at end of file

CrystalMaoFirstPaper 2 - 18 Oct 2011 - Main.CrystalMao
Line: 1 to 1
 
META TOPICPARENT name="FirstPaper"
Deleted:
<
<
It is strongly recommended that you include your outline in the body of your essay by using the outline as section titles. The headings below are there to remind you how section and subsection titles are formatted.
 

Potential Topic: Freemium Open Access

[1] Intro: One of the fundamental rationales underlying the need for open access of zero-marginal cost goods is that it's in the interest of justice

Line: 35 to 32
 -- By CrystalMao - 14 Oct 2011
Added:
>
>
In assessing my examples, perhaps I need to distinguish between a "premium" version that has been transformed into a MC / 0 product (e.g., an MIT education, a physical book) , vs. premium versions that are still MC = 0 (Bostonglobe.com with improved layout and no ads). Does this distinction matter? Is it unethical to restrict access for premium versions that are MC=0, even if the underlying content is available for free?

--By CrystalMao - 18 Oct 2011

It is strongly recommended that you include your outline in the body of your essay by using the outline as section titles. The headings below are there to remind you how section and subsection titles are formatted.

 

Section I


CrystalMaoFirstPaper 1 - 14 Oct 2011 - Main.CrystalMao
Line: 1 to 1
Added:
>
>
META TOPICPARENT name="FirstPaper"
It is strongly recommended that you include your outline in the body of your essay by using the outline as section titles. The headings below are there to remind you how section and subsection titles are formatted.

Potential Topic: Freemium Open Access

[1] Intro: One of the fundamental rationales underlying the need for open access of zero-marginal cost goods is that it's in the interest of justice

[2] Question: But does justice demand that the experience of accessing the information be equal? Does open access = equal access?

[3a] Illustrative Examples:

  • Reading Shakespeare for free as a text file online, v. buying a leather bound edition for $30
  • Boston.com (Trashy) v. Typographer's-dream (Bostonglobe.com): SAME content, vastly different experiences.
  • MIT OCW v. attending MIT
  • Downloading the source code and self-installing v. Paying a consultant to install and configure

[3b] NOT freemium:

  • NYT paywall, 30-day software trials, etc.
  • Difference here is that the "premium" versions of these services offer content and/or access that is not available to non-paying users. In my contemplated system, the access to the fundamental content should be the same.

[4] Proposal: Perhaps a good way to make core information available to everyone, yet preserve free-market esque revenue streams that can

  1. fund the costs and incentivize the efforts of further development,
  2. incentivize people/users towards upward mobility
  3. add more thoughts here,
is to encourage a tiered system that requires people to give away the core information for free, but allows them to charge for the bells & whistles

[5] Problems

  • Is this a sustainable model for key industries - music, movies, where 90% of the value is just the file itself? (Former Rep. Bob Ingles said in a talk I went to last week - "Sustainability means profit")
    • Is it possible to maintain systems where the "premium" version doesn't = premium access to content? At which point do services become or = content?
    • How would this work for software, particularly expensive software like Adobe?
  • Does this address the justice problem? Just because people have access to information doesn't mean that it's in a form that facilitates them to use it.
  • What is the ideal equilibrium-society that I am trying to promote? (think about this)

-- By CrystalMao - 14 Oct 2011

Section I

Subsection A

Subsub 1

Subsection B

Subsub 1

Subsub 2

Section II

Subsection A

Subsection B


You are entitled to restrict access to your paper if you want to. But we all derive immense benefit from reading one another's work, and I hope you won't feel the need unless the subject matter is personal and its disclosure would be harmful or undesirable. To restrict access to your paper simply delete the "#" on the next line:

# * Set ALLOWTOPICVIEW = TWikiAdminGroup, CrystalMao

Note: TWiki has strict formatting rules. Make sure you preserve the three spaces, asterisk, and extra space at the beginning of that line. If you wish to give access to any other users simply add them to the comma separated list


Revision 10r10 - 04 Sep 2012 - 22:02:14 - IanSullivan
Revision 9r9 - 17 Jan 2012 - 21:00:19 - CrystalMao
Revision 8r8 - 07 Dec 2011 - 16:51:57 - EbenMoglen
Revision 7r7 - 10 Nov 2011 - 21:07:48 - CrystalMao
Revision 6r6 - 07 Nov 2011 - 22:23:43 - EbenMoglen
Revision 5r5 - 01 Nov 2011 - 07:51:13 - CrystalMao
Revision 4r4 - 19 Oct 2011 - 17:22:13 - DevinMcDougall
Revision 3r3 - 19 Oct 2011 - 13:29:39 - AustinKlar
Revision 2r2 - 18 Oct 2011 - 04:28:32 - CrystalMao
Revision 1r1 - 14 Oct 2011 - 22:42:08 - CrystalMao
This site is powered by the TWiki collaboration platform.
All material on this collaboration platform is the property of the contributing authors.
All material marked as authored by Eben Moglen is available under the license terms CC-BY-SA version 4.
Syndicate this site RSSATOM