beeware / paying-the-piper

A project for discussing ways to fund open source development.
343 stars 14 forks source link

Community source each feature / functionality #13

Open ximbled opened 8 years ago

ximbled commented 8 years ago

The idea?

I posed this at my previous role, it was largely overlooked as a viable strategy however I think the idea is pitched somewhere between freemium and traditional crowd sourcing.

You create your MLP

But instead of being very lean and scope tight by pruning features / functionality, you attach story points to them regardless. Story points can then be translated into funding. People argue you can't estimate accurately enough, but the T-shirt idea will do well enough. S, M, L

Depending on your project you can say that delivering a L T-shirt will cost you X. By breaking down the functionality as you'd intend to deliver it, the cost is reduced and then shared across the user base.

You then crowd source the funding for each story, depending on what people want from the project most depends on what you deliver and in what order.

As soon as a new T-Shirt is purchased, then that can open up new avenues for the project which can be sized and estimated accordingly.

freakboy3742 commented 8 years ago

It's a common idea - very similar to "bug bounties", but not restricting to bugs. The catch is that you have to be constantly selling new features. An individual kickstarter to fund one non-trivial feature is a lot of effort - you can easily spend the full month of a Kickstarter campaign just doing promotion for the campaign.

So - that means you have to bake the cost of the campaigning process (and the cost of failed campaigns) into your bid price, which increases the amount you need to raise, making the project less viable.

It's also a process that larger companies aren't as likely to engage with - it's easier to ask for one large chunk of money, than lots of little chunks, due to the organizational overhead associated with purchasing.

I feel that we need to focus on getting recurring revenue sources, rather than finding ways to smooth crowdfunding.

ximbled commented 8 years ago

I think this works but only at a larger scale than you've anticipated. I'm also not talking about using kickstarter though that's proven to work (@TryGhost)

I'm talking about a single dedicated crowd-sourcing site per project, there's a really easy to launch Ruby implementation knocking about.

freakboy3742 commented 8 years ago

£500 is, roughly speaking 1-2 days consulting income. So if I want to make a living doing this, I need to:

There's also the process of signing off on new features. As a funding contributor, I might be willing to donate a £200 towards a new front end workflow. But what if I'm not happy with the result. What if I was contributing on the basis that a specific thing would be made easy, but the delivered result doesn't do what I want? Can I withhold payment? And is that fair to the person who delivered?

Very quickly, the on-costs associated with a £500 project vastly exceed the return. This isn't something that works at scale. There are lots of "bug bounty/collective funding" projects that have proposed this idea over the last 20 years, and I'm yet to see one that works.

ximbled commented 8 years ago

So therein lies your motivation. You want to be a consultant. How many consultants have you seen write code?

If you want to be a consultant, be a consultant, but work 2 days a week on £600 day rates and dedicate the rest of your time to whatever it is you think you can do.

£500 is roughly speaking 10-12 hours effective freelancing at a fairly technical level. If that's not something you're capable of then you won't be going down that route. It's like expecting a place on the swim team without being able to swim.

freakboy3742 commented 8 years ago

No, I don't want to be a consultant. That's the point. I want to develop open source code that the community will benefit from. But I don't want to have to do it for free.

nanuxbe commented 8 years ago

GNU health: http://health.gnu.org/ Tryton: http://www.tryton.org/ B2ck: http://www.b2ck.com/ TSF: http://www.tryton.org/foundation/

I really can't say I always agree with those guys or their business model but they are a 3 people company (B2ck) making money around developing their open source software: Tryton It looks a lot like what you want to do, might be interesting to take a look at their business model

ximbled commented 8 years ago

Then why don't you freelance? Or work short term high reward contracts? If you want the recognition from the community and the respect that it garners then you either need to be Richard Stallman which I wouldn't advocate, He's a nice enough guy and he's as far as I'm aware living a fairly free lifestyle.

If however you want to succeed in a more traditional sense, then you need to build a product or an "engine" that is distributable, scalable and reusable (I'll call this "Software").

How you fund that is by selling the professional services that support development. This is a tried, tested and fairly successful model. In so much as you don't hear about the failures until they succeed. At which time they continue to do well, they might see a peak in adoption but that just drives up the need for consultancy and expertise in the area - and who is at the top of that game. well that would be you and your project team.

freakboy3742 commented 8 years ago

Because I don't want to freelance, or work high yield contracts. What I want to do is focus on developing the open source software itself.

Taking Django as an example: We're well past the point where it's proved itself to be of value to the community. It's used in education, in startups, and in fortune 500 companies.

But it's software, and it has maintenance requirements. There are bugs to be fixed. There are new features that we could/should add. There are improvements to the documentation that can be made.

And while volunteers can do some of this work, a project the size and scale of Django requires some dedicated resources. If you want large features delivered in a timely fashion, you need multiple developers to focus on that feature for a period of time. If you want releases to happen on time, you need someone cracking the whip to make sure bug fixes are prioritised correctly. If you want security issues handled quickly, you need someone who can drop everything to triage, fix, and manage the disclosure process.

This is all happening in an environment where there is quite literally billions of dollars in the Django ecosystem. Consultants, Trainers, VCs, and web dev shops, many making very comfortable profits, based on the existence of a stable, feature-filled, well maintained open source project.

It's not an enterprise feature that can be sold - it's basic "make the project exist to the standard everyone expects" stuff. And, lets be clear: when any of these things slip - a release is a couple of weeks late, or a security issue takes a little longer to resolve than we'd like - the Django core team gets abuse from the wider community about "why we're not working harder on Django".

What I want is to be able to access a minute portion of the money in the ecosystem, and direct it into the maintenance of the tool that the ecosystem depends on. If Django didn't exist, none of those businesses would exist either (at least, not in the form they do today). I don't think that's an unreasonable expectation.

mshenfield commented 8 years ago

I stumbled across an existing project, BountySource that provides a bounty interface for issues and pull requests on open source projects. This idea is a cousin of the top level issue and may warrant its own issue - instead of community sourcing every feature, allow people to incentivize issues the want to be resolved. This gives an avenue for monied interests and individuals to get their issues prioritized. For example, IBM opened a $5500 issue bounty on PyPy to get support for the PowerPC architecture. One advantage of this model is that it may require no campaigning by contributors beyond setting up a team on the issue bounty site. Instead, the self interest of companies or individuals drives them to fund issues for which they have a business need or personal desire to see resolved. Similar to #32, the hope would be that developers with expertise in the project could resolve funded issues without significantly detracting from core efforts and community needs.

There are ethical gray areas that come with paying for features. Developers with the best intentions might subconsciously prioritize funded issues over the needs of the general community. Pull requests for funded issues might also be given less stringent oversight because of the carrot attached to them. In the worst case, core contributors might refuse to develop important features, holding them "hostage" until development is funded, even when this hurts the general community and is outside the spirit of FOSS.

wolftune commented 8 years ago

@mshenfield You're completely right about the strange incentives and problems around bounties.

Anyway, here's our (Snowdrift.coop's) complete rundown of all the platforms out there (including BountySource). No need to wait for stumbling ever again: https://snowdrift.coop/p/snowdrift/w/en/othercrowdfunding

There's a link there to our other page describing more about the fundamental problems of bounties, but here: https://snowdrift.coop/p/snowdrift/w/en/status-quo-floss#bounties