Why TDF Doesn’t Do Crowd-Funding

Notice: These are my opinions as an individual, not as a member of the Board of Directors

Note: Slight updates to “accounting” section due to clarification from my good friend :)

From bug reporting on bugzilla, to user/QA mailing lists, all the way to the QA chat, users (and contributors) ask “why not just do a targeted crowd-funding for X,Y,Z.” X,Y,Z has been mostly large projects and/or ideas– including but not limited to Android development, revamping our UI, or even individual “pet bugs” that people have reported. So, in theory crowd-funding sounds fantastic…right? Well, here I’ll try to convince the doubters that TDF doing targeted crowd-funding is indeed, anything but a great idea :)

Accounting

This is perhaps the easiest one to explain. TDF is incorporated in Germany (this is not implying that it would be any easier in another Country) and with that comes of course, German laws (which are likely the same in other countries). These just add a new layer of having to track different “pools” of funding.

The next accounting related issue is what happens if we are short or over (ie. we don’t hit our #’s or we overshoot the #). Well then we’re in a pickle. On one side, if we undershoot the target, do we refund people? Do we merge the money with general funds? Do we just indefinitely hold it in case we ever hit the #? All of these sound quite tiresome/time consuming/confusing. Now if we overshoot, again the same problems arise. Do we refund the extra money? Do we put it in the general funds? Either way accounting for these can be difficult and time consuming.

When push comes to shove, this would just eat up our employee’s (or a tremendously dedicated volunteer’s) time just tracking the #’s and I don’t think anyone would be happy with these results.

Expectations

Donor expectations are another area that becomes overly complicated with targeted funds. Person X donates $100 to “make UI better”, person Y donates $10 to “make UI better.” Now the two don’t agree on what making it better means (one suggests one mock up, the other suggests a radically different mock up). Who wins? If we decide on person Y’s mock up, does person X get a refund because they actually think it’s a horrible UI? What about the difference in contributions – one gave 10x the amount of the other, should that matter at all? Perhaps it shouldn’t…but try explaining that to person X with a straight face. Do we put it to a vote? And then the losers of such a vote get the option to demand a refund?

The reality is that targeted funds come with expectations, and no matter how clear the message of the targeted funds, someone is bound to be unhappy with the result. We’d hate to offend our donors by saying “deal with it” if they get a result that they aren’t happy with and contributed funds specifically for that thing.

Funding for “Less Sexy” Things

Person X has $20, they go to the donation page and they see “general fund” (with some description of what that mean) and then they see “awesome NEW FEATURE!” . . . where do they donate? Exactly, you get the point. While it’s fun to fund new exciting and sexy things, the “non sexy” things are quite (probably a lot more) important. These include paying for infra (quite expensive), employees (who do amazing work), and events. Worst case would be to have a bank account with $50k for “awesome sexy flying monkey feature” and $0 for “general operating expenses.” The response might be “set aside some amount in advance for day to day,” in theory possible, but time consuming and when that amount runs dry – what do we do? Pull “sexy awesome flying monkey feature” from the donation page to “encourage” donors to donate for the necessities?

 

As you can see all of this is quite complicated.

So…Now What?

Well there are indeed options and the Board takes this (and similar) issues seriously. For instance with Android port – we heard, and we acted. We now have a public tender which we are using to solicit bids to start the port to Android. Beyond that:

  1. There are of course grass roots crowd sourcing sites, we don’t vouch for any of them, but we don’t discourage trying to use them. That being said, please note that the risk is on you (the founder of the campaign) and not on TDF to deliver. If you raise $100k and promise to fly everyone to the moon, it’s on you to deliver. But in all honesty, if you raise money and “think” that it might be enough to fix some pet bug or something, ask around the dev channel to see if anyone is interested in doing it for that price – but please please please be aware that if you have no background in programming, you’re likely going to underestimate the cost of development by multiple factors. Before starting a campaign, best to ask for a rough guess at cost from someone who knows the code.
    1. Options: kickstarter of course, and freedomsponsors – again I am not endorsing either, I’ve just seen both used
  2. Volunteer time
    1. Do the leg work! Our group is a meritocracy, doing the leg work tremendously pays off. For instance instead of saying “fix the UI” – build a community, get support for a concrete proposal, get documentation together for functionality, etc… etc… Too often I see a mockup with nothing more (a single image done in an hour or two) and then demands that we implement – this simply won’t work.
  3. Join our public board call – trust me, we’re happy to have the public in (that’s why it’s a public call). If you have strong feelings about something (and are willing to put in work/time/money/etc…) we’re willing to listen. This does not mean jump into the call and demand the world and not give anything in return – again this won’t get us closer to anything other than a headache.
  4. Despite the cons listed above, TDF hasn’t 100% ruled out the possibility, we’re just not ready to make the leap right now. Perhaps at some point in the future it will happen, but until then, I highly encourage our users, donors and contributors, all to find creative ways to get their projects done.

 

 

Successful Bug Hunting Weekend

It was pretty obvious from the beginning that we were having a strong showing from the community to help hunt down bugs in our upcoming 4.3 release – and a big thank you to all of those who participated. A few highlights:

  • At least 15 new faces were present in the QA channel throughout the weekend and are confident many will be around in the future to help with ongoing QA tasks :-D
  • 106 total bugs were reported from Friday until right now
  • 57 of those were against 4.3 beta1
  • 14 confirmed regressions with an additional 4 possible regressions (note that some of these were duplicates (6), but none the less people took the time to report so fantastic news)
  • All but 6 of the 57 bugs have already been triaged
  • 5 bibisects were done on regressions for 4.3
  • 5 bugs have already been RESOLVED-FIXED (crazy!)

Really great work everyone – I’m confident that developers will take it over from here and will be thrilled to see the work that was done this weekend.

Fantastic Day #1 for Bug Hunting

Today we really had an incredible showing of support in testing LibreOffice 4.3 beta1. I saw a dozen or more new faces in the chat and some new contributors were responsible for finding some of the nastier regressions that have now been reported and bibisected.

A big thank you to those who participated and I strongly encourage others to jump into the chat in the next couple days to say hello and see what we’re up to.

34 bugs have been reported against 4.3 beta1 in the past 24 hours. Quite a few of those are marked as regressions and many are already bibisected.

Huge thank you!

Chat: http://webchat.freenode.net/?channels=libreoffice-qa

4.3 Bug Hunting Session

Hi All -

As many of you already know – 4.3 is quickly approaching :-D In order to help our developers make the best release possible we’re asking everyone available to join our bug hunting session this weekend (May 23 – 25).

What is a bug hunting session? Well that’s simple – simply download the latest daily version of 4.3 and use it. Do as many different things as possible using the pre-release and if you hit a snag, report it on our bug tracker. That simple – anyone can do it!

Beta Packages:
Windows: http://dev-builds.libreoffice.org/pre-releases/win/x86/LibreOfficeDev_4.3.0.0.beta1_Win_x86.msi

Debian 32 bit: http://dev-builds.libreoffice.org/pre-releases/deb/x86/LibreOfficeDev_4.3.0.0.beta1_Linux_x86_deb.tar.gz

Debian 64 bit: http://dev-builds.libreoffice.org/pre-releases/deb/x86_64/LibreOfficeDev_4.3.0.0.beta1_Linux_x86-64_deb.tar.gz

RPM 32 bit: http://dev-builds.libreoffice.org/pre-releases/rpm/x86/LibreOfficeDev_4.3.0.0.beta1_Linux_x86_rpm.tar.gz

RPM 64 bit: http://dev-builds.libreoffice.org/pre-releases/rpm/x86_64/LibreOfficeDev_4.3.0.0.beta1_Linux_x86-64_rpm.tar.gz

OSX 32 bit: http://dev-builds.libreoffice.org/pre-releases/mac/x86/LibreOfficeDev_4.3.0.0.beta1_MacOS_x86.dmg

OSX 64 bit: http://dev-builds.libreoffice.org/pre-releases/mac/x86_64/LibreOfficeDev_4.3.0.0.beta1_MacOS_x86-64.dmg

Source: http://dev-builds.libreoffice.org/pre-releases/src/libreoffice-4.3.0.0.beta1.tar.xz

Also the chat room will have experts available to help walk you through downloading, installing, and reporting any bugs found. You can join us here:

Chat: http://webchat.freenode.net/?channels=libreoffice-qa

More information about but hunting session can be found here: https://wiki.documentfoundation.org/BugHunting_Session_4.3.0

LibreOffice can only become better if we continue to grow our list of people testing and contributing back – if you have any spare time this weekend please join us in the chat and say hello. I look forward to talking to many of you!

Florian is Comparing MSO to LibreOffice – Needs YOUR Input

Florian is doing some sweet comparison work between LibreOffice and Microsoft Office and would like YOUR input. What would you like him to test/compare?

Swing by his blog when you get a chance and give him some suggestions :-D His first comparison is already up and looks awesome: http://flosmind.wordpress.com/2013/07/09/libo-vs-ms-commercial/

Contest Results :)

Here is the list of people who participated and the order which they came in :) If you don’t see your name and you should be on there – just let me know.

Thanks to everyone who participated and hopefully many of you will stick around to continue helping – there is always enough work to share :)

Participant
Joel Madero
Thomas Hackert
Joren De Cuyper
Steve Bell
Thomas v.d Meulen
Cor Nouws
Ken Biondi
Jacques Guilleron
Florian Reisinger
Jean-Baptiste Faure
Michael Münch
Zoltan Laszlo
Robinson Tryon
Joan G.
Jan Koberstein
Tim Passingham
Brenda Granados
Ahitagni Mandal
Ralph Aichinger
 

How Many People Use BSA for the first bug report

Thought it  was interesting:

Unique reporters for bug: 8,188

Reporters using BSA for first report: 2,601

% Of Users using BSA for first report: 31.77%

Quite a bit lower than I anticipated but this includes reports from before BSA was created – could explain it.

Follow

Get every new post delivered to your Inbox.