dominictarr / feedopensource

Iteratively Fund Open Source Projects With Bitcoin
feedopensource.com
MIT License
142 stars 16 forks source link

software that needs to exist #17

Open dominictarr opened 10 years ago

dominictarr commented 10 years ago

So, once an iteration or two is complete, this should be (barely) ready to use to for other projects.

If you have funded this already, I hope that you are interested in using it to fund your own project.

What would your project(s) be?

Raynos commented 10 years ago

I would fund http-framework or a new project I want to work on called frontend-framework.

Mainly to acquire collaboration, feedback and user interaction. Also as a source of motivation / commitment. The actual financing of myself is not that important.

As part of using feedopensource I will be forced to do marketing. Make shiny web pages, write blog posts, interact with reddit, interact with hacker news. So far with http-framework I've only focused on the content of the project and informal IRC marketing.

I kind of like the idea that with feedopensource I can start a short "iteration" then whilst I'm getting it funded I will spend my effort on blog posts / twitter / shiny web pages / communication / etc. Once a "iteration" is funded I can focus on content and repeat. At the end of the "iteration" I can create a new one and do more blog posts / marketing around the content I've created in the previous "iteration"

NHQ commented 10 years ago

I'm thinking about funding episode 0 of a series starring Harry Potter who gets a job at a Well Funded Start Up making ROI visualizations for Hollywood Studio PR. Soon he discovers he's optimizing adverts for a live streaming movie about himself, called "Where Is Harry Potter Now?" He tries, and fails, to convey the chasm between his ambivalence without resorting to clowning, and gray magic. When he realizes he can program the codes, and enact his own story in a Hollywood Film, in real time, and at the same time, the end.

mstade commented 10 years ago

I am working on a formal specification of an extensible structured text format, aimed to obsolete markdown and provide a unambiguous specification along with reference implementations of various tools (initially, just a parser.) I have been working on this format for the past six months, and my hope is to have a first draft submitted to IANA in the next couple of months. I'm currently working on it full time, and the work is funded by myself (yay for savings!) I don't expect this to change until the first draft is finished. Naturally, all of this will be open source with permissive licensing. (Currently, the work is under MIT license but still private. Not sure yet whether this license will be used in the public artifacts.)

After the work on the spec draft and reference tooling I hope to be able to focus on less generic products, such as book publishing and screenplay editing tools. At this point, I will likely start looking at other means of funding since I quite likely will be flat broke by then. This method of funding would definitely be a very interesting approach. Kickstarter or Indiegogo might possibly work, but it encourages way too many promises up front and makes it tricky to pivot as you learn more about the problem domain. VC is probably out of the question; I'd rather go back to working for a bank to accrue capital and subsequently bootstrap my initiatives.

Anyway, keep up the great work!

binarykitchen commented 10 years ago

Mad project: I'd try to port the raw avconv video encoder including h264 + libvpx with emscripten to plain JS. And include that in my public avconv package https://github.com/binarykitchen/avconv

NHQ commented 10 years ago

@binarykitchen you get a free head start, cuz somebody did that for node knockout https://github.com/bgrins/videoconverter.js

binarykitchen commented 10 years ago

@NHQ Not really. Have a look at https://github.com/bgrins/videoconverter.js/issues/1

binarykitchen commented 10 years ago

@NHQ And I would include these folks in that project as well.

joates commented 10 years ago

i would like to build a service that connects "digital nomads" and remote workers with a network of "coder friendly" resources around the world (this could be anything from a combined effort to procure a lounge/dorm space conveniently located near a conference venue to a spare room that someone wants to host short-term guests in)

fundamental hosting requirements:

going head-to-head with AirBnB is not my first priority but it would be great if there existed something like this built by hackers, for hackers (i hate using that word but you get the idea :)

related link: https://bitcointalk.org/index.php?topic=169711.0

ralphtheninja commented 10 years ago

@joates Awesome idea. I'd like to help you build it and also back it.

dominictarr commented 10 years ago

@joates you should talk to @jancborchardt he's thinking along the same lines: https://github.com/jancborchardt/hackercouch

dominictarr commented 10 years ago

@joates oh, yeah - and I could totally use something like that!

ghost commented 10 years ago

This would be a really meta project to fund with feedopensource:

I want to build a turn-key hacker temp agency co-op app for building modular applications so that there is always a queue of "shovel-ready" jobs available for module hackers and designers that need some quick BTC. The complete process and pipeline would be transparent to all parties engaged in the economic transaction and each phase would generate a tangible product that is independently useful outside the project roadmap itself. The agency software would promote incremental reusability and transparency at each level by default, because defaults harness the virtue of laziness, the most powerful of the 3 virtues.

The easiest way to build this will be to build on top of feedopensource itself as a higher-level layer to handle task coordination and disbursement of the raised money in a fair and transparent way.

There are 3 phases, each of which feeds into a work queue, so any starving hacker/artist who needs some work can unshift an item to obtain a mutex on that queue item for a time-limited span. The mutex prevents people from accidentally working on the same task item in parallel, but it will be possible to coordinate and collaborate on mutexed work using a github-style forking model. The phases can each happen iteratively in parallel, but some initial amount of work must be done in the preceeding phases first.

The first phase turns the client requirements into a dependency graph of tasks. Clients with BTC fill out a web form detailing what kind of software they need and put down some BTC as an initial down payment into the product wallet and to cover the application filing fee. Clients should be discouraged from specifying too many of the specific technological choices since that can get in the way of decomposing the problem with sufficient modularity. Nevertheless, an in-built referral system could help with punting projects to other co-ops that have more appropriate expertise for the project. Once the work for the requirements is done, the people who did the work get paid out of the budget based on how much time the task took plus some fixed amount. The module-driven project road map is then given back to the client. Any changes to the project plan as the project evolves will feed back through this planning pipeline and into the planning work queue.

All of the open source modules in the project plan that don't yet exist will be created as stub repos with a feedopensource badge in the readme. The client will green-light development on each open source module by funding it individually with BTC or with script that funds every project in the planning graph.

Each open source module has its own wallet from feedopensource but all of the glue and design work tasks that aren't open source module will be billed from the main project wallet based on an hourly rate and paid out immediately upon completion of the work.

NHQ commented 10 years ago

@substack great idea! An actual co-op organization using that could pool revenue and disperse it according to w/e their agreements are (hours worked, member splits, some combination). This also helps with the problem of pricing code writing. The co-op shares (and can easily amend its own rules), so the goal is simply to charge the client enough for the work, and know your members.

This makes me wonder if strapping it to feedopensource is the right. Payment is out of scope.

If you are using it in a completely decentralized way, then using feedopensource makes some sense. But then you have a separation between the person divvying module orders, and the coders, and potentially coders against each other, in the tradition of notable freelance websites. Plus, the work, in these cases, is paid for by the client, right? It is not a crowd funded thing.

I think the most important piece is the one that gets some daring company to develop something in that way. The business end.