Changes

<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}</noinclude>

<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}</noinclude>

==Mako's Essay on Funding Free Software Projects (extract)==

==Mako's Essay on Funding Free Software Projects (extract)==

''Regardless of the steps that a project chooses, transparency will act in a central role in maintaining volunteerism.'' — Mako Hill

''Regardless of the steps that a project chooses, transparency will act in a central role in maintaining volunteerism.'' — Mako Hill

I thought we could use this text, taken from Mako's essay, [http://mako.cc/writing/funding_volunteers/funding_volunteers.html "Problems and Strategies in Financing Voluntary Free Software Projects"], as a starting point for a discussion on what sorts of activities Sugar Labs should be funding. In the essay, Mako takes a strong stance against the introduce of paid labor into a primarily voluntary free software project, so this is far from a neutral starting point. Nonetheless, let the discussion begin! --[[User:Walter|Walter]] 13:26, 28 May 2008 (UTC)

I thought we could use this text, taken from Mako's essay, [http://mako.cc/writing/funding_volunteers/funding_volunteers.html "Problems and Strategies in Financing Voluntary Free Software Projects"], as a starting point for a discussion on what sorts of activities Sugar Labs should be funding. In the essay, Mako takes a strong stance against the introduce of paid labor into a primarily voluntary free software project, so this is far from a neutral starting point. Nonetheless, let the discussion begin! --[[User:Walter|Walter]] 13:26, 28 May 2008 (UTC)

"The safest way for voluntary free software organizations to spend money without compromising voluntary labor is to not pay for labor -- and the production of code in particular -- or to fund labor indirectly.

"The safest way for voluntary free software organizations to spend money without compromising voluntary labor is to not pay for labor -- and the production of code in particular -- or to fund labor indirectly.

"One great way to do this, employed frequently by the Debian project, is to use donations to '''purchase hardware to help facilitate development'''. The most frequent and largest types of expenditure by the Debian project and its supporters is hardware for servers, other forms of infrastructure, and bandwidth. Each of these are viewed as shared resources within the project which avoids the appearance of paying an individual and valuing some contributions more than others — even if an individual makes disproportionately large use of the machine or infrastructure in question. When a developer steps down, the project infrastructure they use is passed on to another volunteer.

"One great way to do this, employed frequently by the Debian project, is to use donations to '''purchase hardware to help facilitate development'''. The most frequent and largest types of expenditure by the Debian project and its supporters is hardware for servers, other forms of infrastructure, and bandwidth. Each of these are viewed as shared resources within the project which avoids the appearance of paying an individual and valuing some contributions more than others — even if an individual makes disproportionately large use of the machine or infrastructure in question. When a developer steps down, the project infrastructure they use is passed on to another volunteer.

"Another good way to fund projects is to '''build "capacity."''' Capacity describes work or resources of any organization devoted to something other than the groups' core goal but that makes the project more effective or efficient. Developing or building an accounting system is a good example of capacity. Because it is outside of the core goals and work of the project, funding capacity is less likely to crowd voluntary workers out. Since infrastructure and increased or improved capacity can help an entire project run more smoothly, funding capacity in this way can help a voluntary organization become more streamlined and effective with only very minimal risks of crowding out volunteers, affecting transparency, or resulting in a lower quality product.

"Another good way to fund projects is to '''build "capacity."''' Capacity describes work or resources of any organization devoted to something other than the groups' core goal but that makes the project more effective or efficient. Developing or building an accounting system is a good example of capacity. Because it is outside of the core goals and work of the project, funding capacity is less likely to crowd voluntary workers out. Since infrastructure and increased or improved capacity can help an entire project run more smoothly, funding capacity in this way can help a voluntary organization become more streamlined and effective with only very minimal risks of crowding out volunteers, affecting transparency, or resulting in a lower quality product.

"DebConf, the annual Debian conference, is a good example of '''strategic conference funding''' and is how the Debian project spends the vast majority of funding each year. Lodging, bandwidth, the conference venue, and food are normally paid for all attendees based on a first-come-first-served basis until funds are depleted. Additionally, travel aid is offered on a combination of need and merit based systems going first to speakers with accepted proposals, then to official Debian developers, and finally to qualified contributors to the project over the previous year. Funded conference attendance acts both as a reward for active volunteers and a step toward creating a positive, fun, and highly educational event for all attendees. Each year, there are participants who are less involved in the Debian project before the conference but who increase their involvement after. Additionally, DebConf acts as a venue for airing ideas and proposals between developers and for gathering feedback on controversial issues.

"DebConf, the annual Debian conference, is a good example of '''strategic conference funding''' and is how the Debian project spends the vast majority of funding each year. Lodging, bandwidth, the conference venue, and food are normally paid for all attendees based on a first-come-first-served basis until funds are depleted. Additionally, travel aid is offered on a combination of need and merit based systems going first to speakers with accepted proposals, then to official Debian developers, and finally to qualified contributors to the project over the previous year. Funded conference attendance acts both as a reward for active volunteers and a step toward creating a positive, fun, and highly educational event for all attendees. Each year, there are participants who are less involved in the Debian project before the conference but who increase their involvement after. Additionally, DebConf acts as a venue for airing ideas and proposals between developers and for gathering feedback on controversial issues.

"A related, and sometimes overlapping model of funding involves funding '''code sprints'''. Popular in the Python and Zope communities and with increasingly popularity elsewhere, sprints are intense sessions of development — usually around one week long. They are used as catalysts for development and have seen major leaps forward in the development of features and code within very small amount of time. Sprints are like conferences in most aspects except that the emphasis is more on the production of code and sustained hack-sessions than on presentations and discussions. They also usually involve less people than a conference and attendees are usually limited to the most actively involved volunteers on a project. The Plone Foundation and SLX Debian Labs in Norway has effectively used the funding of sprints to accomplish time-based development goals.

"A related, and sometimes overlapping model of funding involves funding '''code sprints'''. Popular in the Python and Zope communities and with increasingly popularity elsewhere, sprints are intense sessions of development — usually around one week long. They are used as catalysts for development and have seen major leaps forward in the development of features and code within very small amount of time. Sprints are like conferences in most aspects except that the emphasis is more on the production of code and sustained hack-sessions than on presentations and discussions. They also usually involve less people than a conference and attendees are usually limited to the most actively involved volunteers on a project. The Plone Foundation and SLX Debian Labs in Norway has effectively used the funding of sprints to accomplish time-based development goals.

"While conferences and sprints can be a clever way to spend money without sacrificing the voluntary nature of development projects, it is worth keeping one important caveat in mind. When a project selects people for funded attendance at the expense of others, it demonstrates favoritism that can be divisive. In the process of organizing these events, it is important to '''maintain a high degree of transparency and fairness'''. Organizers should use published and fair criteria to determine conference funded attendance and leave attendance open to all. Good criteria for fair selection includes "first come, first served," constructive activity on mailing lists, the number of important commits to a source code or documentation repository, or a good reputation among fellow developers (e.g., as determined by a fair and representative committee)."

"While conferences and sprints can be a clever way to spend money without sacrificing the voluntary nature of development projects, it is worth keeping one important caveat in mind. When a project selects people for funded attendance at the expense of others, it demonstrates favoritism that can be divisive. In the process of organizing these events, it is important to '''maintain a high degree of transparency and fairness'''. Organizers should use published and fair criteria to determine conference funded attendance and leave attendance open to all. Good criteria for fair selection includes "first come, first served," constructive activity on mailing lists, the number of important commits to a source code or documentation repository, or a good reputation among fellow developers (e.g., as determined by a fair and representative committee)."

==Funding FOSS Projects to Increase Participation==

==Funding FOSS Projects to Increase Participation==

Mako's essay (http://mako.cc/writing/funding_volunteers/funding_volunteers.html) identifies the negative impacts of paid labor in free software projects.  While I concur with his observations, I also feel that paid labor can not only be beneficial but essential in certain situations.  This seemingly dichotomous statement becomes quite consistent when we introduce another variable to the argument.  This variable is the “scope of the community.” If we are to consider a bigger universe of the community – a universe that encompasses the lesser developed regions of the world – then each of the risk factor has to be re-examined within the context of its scope.  The statement “when it comes to voluntary work and paid labor, you can have one or the other but not both” should thus be extended to say that “In a given scope, when it comes to voluntary work and paid labor, you can have one or the other but not both.“ Let us first examine the need for paid labor.   

Mako's essay (http://mako.cc/writing/funding_volunteers/funding_volunteers.html) identifies the negative impacts of paid labor in free software projects.  While I concur with his observations, I also feel that paid labor can not only be beneficial but essential in certain situations.  This seemingly dichotomous statement becomes quite consistent when we introduce another variable to the argument.  This variable is the “scope of the community.” If we are to consider a bigger universe of the community – a universe that encompasses the lesser developed regions of the world – then each of the risk factor has to be re-examined within the context of its scope.  The statement “when it comes to voluntary work and paid labor, you can have one or the other but not both” should thus be extended to say that “In a given scope, when it comes to voluntary work and paid labor, you can have one or the other but not both.“ Let us first examine the need for paid labor.   

In most voluntary free software projects there is little or no contribution from lesser developed countries.  In developing countries there is a general lack of awareness about the benefits of and the opportunities for volunteering. Two basic reasons stand out: (1) programmers do not have the necessary skill sets to contribute; and (2) the economic conditions make part-time employment more attractive than volunteering.  Therefore, if the process is left to natural growth there will continue to be a disproportionately lower share of participation from the developing countries.  This will not only exclude a large segment of the population, but it will also starve the project from the diversity of solutions that may be necessary to cater to the different social and educational environments of other countries.  Therefore, explicit intervention is required.   

In most voluntary free software projects there is little or no contribution from lesser developed countries.  In developing countries there is a general lack of awareness about the benefits of and the opportunities for volunteering. Two basic reasons stand out: (1) programmers do not have the necessary skill sets to contribute; and (2) the economic conditions make part-time employment more attractive than volunteering.  Therefore, if the process is left to natural growth there will continue to be a disproportionately lower share of participation from the developing countries.  This will not only exclude a large segment of the population, but it will also starve the project from the diversity of solutions that may be necessary to cater to the different social and educational environments of other countries.  Therefore, explicit intervention is required.   

The intervention could be in the form of setting up focused teams in various regions, which would be funded for a limited period of time.  During this period the team would develop capacity by participation in the project and create a FOSS culture in that region.  The team would move towards self sustainability by generating revenue from services, and as a by product, create economic opportunities for other participants.  This would create an ecosystem around FOSS in the developing world.  The definition of capacity building, as envisioned in Mako's essay, would be expanded to include the training of the team members; a core team of developers would have to be paid for a limited duration.

The intervention could be in the form of setting up focused teams in various regions, which would be funded for a limited period of time.  During this period the team would develop capacity by participation in the project and create a FOSS culture in that region.  The team would move towards self sustainability by generating revenue from services, and as a by product, create economic opportunities for other participants.  This would create an ecosystem around FOSS in the developing world.  The definition of capacity building, as envisioned in Mako's essay, would be expanded to include the training of the team members; a core team of developers would have to be paid for a limited duration.

Now let us examine why such a set up would not perturb the dynamics of the project.  For example, if we revisit the negative fall outs of  paid development in the X Consortium, it can be seen that root cause was that the paid group had significant weight – both in influencing the direction of the project as well as the output they produced.  As the offshore teams would be striving to come at par with the mainstream community it is unlikely that they would produce the negative impacts.

Now let us examine why such a set up would not perturb the dynamics of the project.  For example, if we revisit the negative fall outs of  paid development in the X Consortium, it can be seen that root cause was that the paid group had significant weight – both in influencing the direction of the project as well as the output they produced.  As the offshore teams would be striving to come at par with the mainstream community it is unlikely that they would produce the negative impacts.

I am glad that Mako concluded his essay with the sentence, “Done critically, creatively, and transparently, voluntary free software projects can use money and paid labor to a tremendous benefit that only magnifies their accomplishments.” I think it is important to explore mechanisms for expanding the reach of FOSS development in the developing world; paid labor may well be one such mechanism.

I am glad that Mako concluded his essay with the sentence, “Done critically, creatively, and transparently, voluntary free software projects can use money and paid labor to a tremendous benefit that only magnifies their accomplishments.” I think it is important to explore mechanisms for expanding the reach of FOSS development in the developing world; paid labor may well be one such mechanism.

- Tariq, Sep 8, 2008

- Tariq, Sep 8, 2008

I have created a [[Grant Application Calendar]]--[[User:Mokurai|Mokurai]] 21:52, 15 December 2008 (UTC)

I have created a [[Grant Application Calendar]]--[[User:Mokurai|Mokurai]] 21:52, 15 December 2008 (UTC)