A new method of supporting FOSS?
- by James
I have been kicking an idea around for sometime and wondered if something of it's nature hadn't already been invented.
The premise is a website that integrates code management, project/team management, and micro-transactions.
Donations, in and of themselves, are a sporadic, and unreliable method of supporting developers. Furthermore most free software that accepts donations is started by programmers ,be it to learn, because of a hobby, or because they saw a niche that needed to be filled.
There is no method in place of of saying "hay, the FOSS community needs this kind of software, will someone develop it, and accept donations!?"
Programmers should be programming, not busy begging for money.
Basically the idea is people can go to the site in question, and start a project or make a request. Anyone signed up with the site can start a request. Each member account is free to support or "upvote" a project request.
Requests and the associated number of votes let programmers in the community know the needs of the community.
When a project is started a request for developers can be put forth. Developers have a ranking based on commits to other projects. The project founder can send invites to known Developers, or accept invites from members based on developer ranking.
Once the project has at least one team-member, an objectives sheet or "draft" can be put out, listing design, goals, and features. The founding member and each team-member may contribute to this sheet. Each "milestone", or "Feature" is represented by an article. An article is any unit of a draft that can be voted on by The Project Founder, Team-members, and contributors...which brings me to the next half of this idea.
--Microtransactions--
People signed up with this hypothetical website can purchase credits which then can be transfered to projects they would like to support. Anyone who transfers credits to a project is known as a contributor to that project.
At anytime a Founder, or the lead team-member may submit an article, or a design (multiple articles) for consideration. All team-members, as well as the Founder, can vote once for each article freely. Contributors may vote yes or no on a number of articles (independent of any given meeting where a particular design or article is considered) equal to the number of credits they have placed into a contributors fund for that particular project.
A contributors fund is a proxy between a sites credit account, and a projects credit account. It is sort of like a promise to contribute, instead of an actual contribution.
Contributers may place constraints on particular articles such that if those constraints (a yes or no vote) are satisfied then a manually specified amount of credits is automatically transfered to the project account. This allows a project to develop based on the needs of those who may (in the future) financially rely on the project.
--- Code commits & milestones ---
When a team-member makes a commit, they may specify if it's a minor commit, a bug fix, a compatibility patch (i.e. for a new platform), or a milestone (an article voted on previously).
People signed up with the website, may download the updated project and test it to see if the programmer's assertion is true about the commit. A report may then be filed on a small form, giving a one or two paragraphs, and a positive or negative confirmation of the programmer's goal for that particular commit.
After all milestones for a particular draft are complete, a new draft is submitted for voting. Also funds may withdrawn by each team-member based on the proportion of commits and milestones confirmed (fulfilled the stated purpose) for each programmer.
--- voting ---
Members, contributor, and non-contributor, may make priority requests for particular articles of a draft. The project founder may or may not opt to fill those requests based on the volume of upvotes. A fulfilled priority request means that any team-member that makes a community-confirmed commit for an article is, when all articles for the draft are fulfilled, granted a portion of project credits in proportion to the average priority of all the articles he committed.
---- Notes ---
While this is horribly prone to design-by-committee the one saving grace is that the lead team-member may place constraints on a draft such that some, or ALL articles must be voted yes. Commits may not begin until a draft satisfying said constraints is approved.
What does SO think, is this idea feasible? Does anyone see major problems with this? Is there any insights, or improvements that could be made?
