[Ardour-Users] Could this solve Ardour's financial headache?
pshirkey at boosthardware.com
Tue Jan 13 20:20:00 PST 2009
Thomas Vecchione wrote:
> Its not so much that you are having problems expressing oyur ideas,
> but more that I don't necessarily agree with them;)
That's fine, disagreement will help us move this topic forward. I would
rather get useful feedback like below than be ignored completely.
> On Tue, Jan 13, 2009 at 9:59 PM, Patrick Shirkey
> <pshirkey at boosthardware.com <mailto:pshirkey at boosthardware.com>> wrote:
> Mantis and Embedded browser integration
> 1: Integrate Mantis into the website so the bounty system is more
> visible, accessible and auto updated.
> This I agree with, and is already being worked on in some small part I
> believe. Don't ahve to much information at this point though.
> 2: Add an embedded browser to Ardour that can be disabled with a
> config setting if desired.
> 3: Make sure the embedded browser will not attempt to access the
> internet if the system is not connected. Simple check of ifconfig
> should confirm without any overhead.
> 4: Point the embedded browser at http://ardour.org
> 5: Make sure it is displayed at startup by default. Config setting
> to disable.
> This I disagree with. It would pull in more dependencies for ardour
> for something that is limited in usefulness to be honest. There is no
> reason to have a full browser, the most I might think about might be
> something that can parse an XML/RSS feed to be honest, but even that
> is a bit questionable to me.
Ok. So not a full browser but instead a simple xml parser? Hmm that
sounds exactly like the concept of a ticker. The difference is where it
is displayed. The dependency issue can be solved the same way all the
other library dependency issue are solved. As in make them a part of
the code base and hook them up statically and be done with it. Firefox
has a great embedded platform called xulrunner. It provides a complete
embedded firefox interface and library. The main reason for suggesting
embedding a browser completely is that payments can be made from inside
the app that way. This would make it easier for people to give and there
would only be one payment gateway to maintain online.
> Fundraising and Mantis fund integration
> 1: Create a Mantis fund and integrate it with the donations and
> bounty system on the website.
> 2: Run a fundraiser to build up the Mantis fund.
> 3: Funds raised could be matched by upto 1 month of subscriptions
> with total pool of $3000
> The problem with this is that it ignores the primary problem and goes
> for a secondary issue. If we aren't raising enough money to pay the
> primary developer, which is the goal of the raising money, then we
> need to address this first, before we take money away form the goal of
> paying the primary developer and put it towards a secondary(IMO) goal
It doesn't ignore anything. It simply allocates one months worth of
subscriptions to the initial fund. I am assuming that Paul is already
getting paid in other ways so that this money can be feasibly "set
aside" for one month. The majority of the money would end up going back
into Pauls hands anyway as he would most likely be the one to implement
the Mantis item. He could also optionally take a handling fee or
commission for all cash that was paid out to other developers which is a
fair deal as they would not have an opportunity to make money if Paul
had not made it possible in the first place.
> Allocation of funds
> 1: Setup a voting system for the Mantis bugs/features
> 2: Encourage users to vote for the features/bugs they want to be
> worked on next.
> 3: Assign an appropriate cost for the most popular features.
> 4: Allocate a part of the Mantis fund, say upto half of the cost
> to the 5 most popular features and let the community fund the
> 5: When targets are met start work on the feature and take the
> cash out of the system.
> 6: When the feature is finished give the cash to the Dev/s who
> earned it.
> 7: Let people know that a new voting round it in process for x
> amount of Mantis items.
> 8: Return to 2.
> And while I don't disagree with this necessarily, there are other
> problems that need to be addressed with the bounty system regarding
> payment, etc. as well, but this is going to veer off to a different
> topic pretty quick I think.
These problems need to be sorted out before the integration work is started.
> If the core changes for this system do not make the cut for a
> short period of developer time and attention (say 1 month) then
> there is no way the user community can be expected to make more
> effort to fund Ardour development than they currently do.
> I get the feeling that people are actually happy with the current
> system and quite possibly don't want to make it more effective
> because then we would have a system that actually meets its goals.
> This is a scary idea. Ardour funding actually meeting Pauls
> targets. After 12 years of not being tenable I can see how it
> would make some people uncomfortable. Nobody wants to see the
> baby* grow up and become an adult.
> I sure hope that last paragraph is sarcastic. It is hard to tell in
> text. If it wasn't then what is the point of this entire discussion
> if not to suggest new plans of action to be moved on. (Obviously the
> latter part of that still needs to happen).
There is lots of discussion but not much consensus. I definitely get the
impression that a large number of people don't actually want to see
Ardour funding succeed. There are many reasons for people to feel this
way. This is what I see from my position. I hope to be proven wrong though.
Boost Hardware Ltd.
More information about the Ardour-Users