User Expectations and the Reality of Our Community

Notice: I debated if I should write this or not – so in advance, I apologize if it comes off as overly aggressive.

Lately I’ve been seeing a spike in users demands both on the user mailing list, the chat room, and on bug posts. More and more I’m seeing things like “this is a blocker for me and therefore it should have a higher priority.” This is truly a problematic trend and I hope that those reading this will take a moment to reflect on the impact that such comments have on our community.

It is incredibly easy to point fingers and tell someone else to “fix it.” Fortunately, that is not how our community has worked, nor is it how it works now. Angry comments that criticize a regression, or try to manipulate priorities/importance in order to get higher attention, is only bound to lead to developers  and QA becoming unmotivated, avoiding the bug completely, etc . . .

So a couple incredibly important points:

  1. The Document Foundation (the non profit organization behind LibreOffice) has zero (yes, not one) paid developer. The implication of this is that there is literally not one single person on the project who can dictate how bugs are fixed.
  2. There are paid developers being paid by other companies – again TDF has zero power to influence these companies. They do incredible work and TDF has helped to develop an ecosystem where such third party, independent, companies can thrive.
  3. The remaining portion of our commits are wholly from volunteers. What does this mean – again, we have no power to dictate how a volunteer uses their time.

So what we try to do (at least in QA) is to do as much work as possible to help move the bug along, and then, it’s truly out of our hands. Things that can be done:

  1. Debug (for crashers especially): https://wiki.documentfoundation.org/Development/How_to_debug
  2. Bibisect (for regressions, 64 bit linux required): https://wiki.documentfoundation.org/QA/HowToBibisect
  3. Clear, simple reproducible steps + clean document for a test case.
  4. Prioritize correctly: This means WITHOUT bias of “this affects me” (honestly if developers are going to trust our priority/severity at all even as a guidance on what to fix, we must do this without bias, I completely avoid prioritizing my own bugs, even after 3 years on the project and thousands of bugs triaged). For guidance: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
  5. Most important at all: GIVE BACK. More and more I’m seeing users who give no time and demand the world – this is really just a way to demoralize the entire community. There are lots of teams – please do more than complain, because that really does nothing to improve the greatness which is Libreoffice.

Two particularly troublesome things have come up recently, more so in the past. Complaints about regressions have increased and this demand on developers to fix their regressions immediately, drop all other priorities, etc . . . etc . . . Some have gone so far as to ask if developers have “any responsibility to test their commits.” Rest assured – they test like crazy, but with >10,000,000 lines of codes, crazy shit happens. So getting involved earlier (download the pre-releases, daily builds and test) again….helps us help you. It’s easy to wait until a release, give zero time, and then start spamming wherever possible to complain. Second, enterprise users demanding we do things for free and prioritize highly because “this makes using LibreOffice in my office impossible.” For those of you using LibreOffice in an office, who are making money off of all of our volunteers incredible work, please consider getting support . . . making money off of others work and then complaining about the product you get is surely not the best approach to building a happy and healthy open source project.

So lastly – the options for bugs, they are pretty clear but I find myself having to repeat them over and over again:

  1. Submit a patch yourself (the code is free, go check it out);
  2. Find a family, friend, spouse, etc . . . to submit a patch (what are friends for right? 😉 );
  3. Pay for a fix (there are companies out there that are really quite fantastic);
  4. Wait patiently (yes that’s the last option – wait, complaining helps no one).

If you choose option #4 – I highly suggest doing the steps  from the QA side to help move it along (help us help you!) – debugs and bibisects in particular.

Advertisements

About joelmadero

EE32 6D0F 81FF 6FAC 5AD8 10E4 0141 27C6 8FFB 1B14

37 responses to “User Expectations and the Reality of Our Community”

  1. RobJN says :

    Hi Joel,
    I see similar comments on OpenStreetMap’s mailing lists/forums etc..

    The positive to take away is that LibreOffice is growing in popularity and as such you have now picked up a group of users who likely do not understand the open source nature of the project or that there are no paid employees in the Document Foundation. The fact that they are taking the time to write in implies that LibreOffice is important to them 🙂

    The negative, as you’ve pointed out, is the demoralising impact on the community.

    Best thing to do is to support you developer community by reminding all people who comment in such a way that the project is volunteer driven and that clear factual bug reports are likely to get dealt with quicker than incomplete reports that have an aggressive tone of language.

  2. Simo Kaupinmäki says :

    You make a good point: it is absolutely essential that there is a motivated bunch of people testing the software, reporting bugs, and of course fixing them. On the other hand, for most users an office productivity suite is just a tool to get some specific tasks done. It is understandable that they will get grumpy if there are complications caused by a bug or missing feature in the software.

    One thing that may aggravate the situation is that the LibreOffice download page is primarily designed to promote the Fresh branch, which is likely to have more regressions than the Still branch. It may therefore go unnoticed by some users that there is also a more mature version available. One way to reduce negative feedback is to make the Still branch more visible (perhaps even the primary option) on the download page and explain the difference between the two branches in plain words.

    • joelmadero says :

      Hey Simo – yes this is something many have said. The problem is that if we have a ton of bug reports against the “still” and it’s fixed in the “fresh” then we hit a problem where we tell everyone to go upgrade. We get much pickier about backporting to the “still” version – requires quite a bit more testing which in terms of man power, we just don’t have. But ultimately that’s a decision for the website team to make, and they’ve talked about it over and over again and for whatever reason – they’ve decided to stick with the “fresh” version.

      • bmichaelsen says :

        If we would default to “still” on the website, a lot less people will use “fresh” and a lot less bugs will be filed and fixed before that release becomes “still”. So doing that would change nothing for the majority that downloads the default: They would use a release with roughly the same refinement as before, but it would be called “still” instead of “fresh”.

        The only reason “still” is more refined than “fresh”, is that it was used by a broad audience in production over an extended amount of time and we had time to collect reports and push out fixes.

        Making “still” the default will do no good for those using the default download, but it will remove the option for those consciously making a choice for a more conservative option.

      • Simo Kaupinmäki says :

        What bmichaelsen says, sounds as if developers basically regard the Fresh branch as beta software and its users as testers. Indeed, when descriptive labels for the Fresh and Still branches were introduced a while ago, the more mature branch was initially called Stable, suggesting that the Fresh branch wasn’t considered quite stable.

        The idea that testing should be done by the majority of users sounds backwards to me. Granted, from an engineering point of view this helps in finding and fixing bugs, but only after they have caused large-scale frustration among users. How can it be preferable to have a hundred users being hit by the same bug and filing several duplicate reports, as opposed to a single user filing the bug and it being fixed before it hits the other 99 users? That is bound to have a negative effect on the reputation of the software and people’s confidence in it. People who stick with, say, Apache OpenOffice because they think it is a more stable alternative will not be contributing to the development of LibreOffice at any stage of the cycle (except through OpenOffice code that may eventually be merged with LibreOffice).

        Defaulting to the stable version seems to work fine for other free software projects. Just consider Debian, whose Stable version is widely regarded as the epitome of stability, yet there are plenty of experienced users who prefer to have the not-quite-stable Testing version as their primary desktop system, because they want to take advantage of its new features. This has the additional advantage that experienced users are likely to be better prepared than novices to deal with bugs. As far as I can see, LibreOffice’s Fresh branch is a little like Debian Testing, whereas Still branch is more comparable to Debian Stable (even if the development cycle is considerably faster and support time shorter for LibreOffice), but LibreOffice developers don’t seem to have the same confidence in and commitment to their user base.

        I think LibreOffice’s release plan is actually rather user-oriented and flexible. It allows you to stay with the Still branch for a while if you prefer stability, or alternatively you can start using the Fresh branch at a stage that suits your needs. This choice is, however, played down on the download page. The Still branch needs not be the only option that is promoted, but helping all users to make an informed decision between the two branches would show good faith and very likely reduce negative feedback.

  3. GT says :

    Thanks for the blog entry. I think you touched a critical point in open source software project in general. The more OSS is used in professional environments (I don’t mean commercial, but people who need to get work done), the more people rely on the software. Hence – positively spoken – increased expectations correlate with increased dependency on e.g. LibreOffice. This is good, per se.

    The problem is, what happens in the case of regressions in new software versions? I know that LibreOffice puts them on a higher priority, but still this does not ensure that someone (I know most are volunteers, of course) fixes this regression.

    Let’s use an example: There is this awful regression on .eps documents. From LO 4.2 onwards, eps graphics in documents are neither displayed nicely nor do they properly print or export to PDFs. The problem is that – in an university environment – many figures, graphs, … are in .eps format and they are in dozens/hundreds of existing documents. All these documents cannot be used anymore, but need to be manually reworked (if it is not too late and a student remarks that figure x, y and z is not readible in the document they received). This definitively hampers professional work. And, as said, there is no money stock that can be used to pay for fixes, but rather bug reporting, testing and individual freedomsponsor-type of donation.

    What I point to, is the inherent problem in OSS, that software like LibreOffice targets professional users, but has difficulties to fix all severe regressions early enough. The LibreOffice community is very vibrant and hundreds of bugs/regressions are quickly fixed, but there is a problem with some severe regressions that are not fixed. These deter professional (as said, not neccessary commercial) users. As mentioned in the bug entry, this .eps regression had the effect that many in my work group (had to) divert to MS Word again. I don’t agree with that, but this is how users can be lost: if existing work of them is lost.

    My comment shall not be offensive in any way, so please do not misunderstand. I just want to point to an inherent problem of OSS software development being based on volunteer work. I don’t know how to solve the problem, but at the same time, OSS software risks losing ordinary users that just want to get work done (and many of them have no clue that they are using OSS software)….

    • joelmadero says :

      Hey GT – no offense taken and all valid points. That being said, I think the solution is pretty crystal clear and the four options I put out there are essentially the mindset that our users have to take. For people making money using our product (which includes professional users generally — I believe by definition professional means using it an office setting), not correlating Libre with “I won’t pay” because that is what is dangerous.

      As for regressions – the nice thing is that if there is a nasty regression we keep all previous versions of LibreOffice online. So if someone sees a major problem that they cannot cope with in a current release, they can use an EOL release that previously worked for them and wait until the regression is fixed. Beyond that, I think anyone replacing 20 computers or more that would have MS Office 360 and thus paying $100 per machine per year, should consider buying a support package, or getting an in house developer. This is clearly a different mind set, and one that is hard to teach the “average user” but it’s the mindset that will allow us to continue moving forward. Ultimately it’s of course cheaper for the end user also but not a cost of $0 — which unfortunately is what more and more users (professional and non professional) are equating “Libre” to mean.

      I see this as a challenge but a manageable one, educating people is always hard but quite rewarding after you succeed.

  4. mz says :

    “Rest assured – they test like crazy” – the question is what do they test? I think they test if the build is building, often only in their Linux environment, not the features itself… I have seen only few developers who introduce new features in the LibreOffice codebase along with the tests. Bugs are fixed without testcases to catch regressions in the future. Late features are OKeyed “because it (code) looks good” and they in general are not properly documented for QA people to test them. Most often every new branch receives code rewrites (as new Calc core), so in a point in time you had a stable branch with all of old Calc bugs and fresh with new bugs (new core making old bugs irrelevant and mostly obsolete)… There is no QA OK for a feature uplift. Therefore in master there are many new, untested and regressed features which cannot be backed-out and releases are produced that are unusable (because their time has come). This is the main problem for LibreOffice code management. You pretty much don’t have a stable branch, because code changes every 6 months. And as it is changing, the fixes from fresh branch are often not backported. In worst case scenario a user cannot move to fresh branch because of new regressions, which could be already fixed in next fresh, but the original stable bug is still there. That is why people starting to be aggressive, because it seems that QA do not have powers to control what code is added to the codebase. IMHO you can properly manage bugs even if you have volunteers only. Maybe the time has come to change the code workflow. Give more power to the QA. Those few heroes have to test two branches, with their RCs, not mentioning alfa branch and master branch. Too much work for too few people… 4 code branches (4.2.x, 4.3.x, 4.4.x when branched, next master)! Not mentioning Linux, Windows and MacOS operating systems… And not mentioning dozens of Linux distros, few Windows. Go figure…
    Luckily for developers there will be Gerrit tests for every commit in the future, but it is just for the buildable code – not a proper user experience (you can have 100% proper code which breaks a feature in the suite). There is a crashtest automation in place, so crashbugs are getting fixed. But some kind of user experience automation have to be put in place to autotest most common user actions, maybe those where code changes most. Who will volunteer to implement that?
    Unfortunately Coverity-clean-best-in-open-source-bug-free code will not bring LibreOffice more lovers if there are still user experience bugs, which the other commercial suite doesn’t have (or worse – older LO or AOO are unaffected).
    All in all I hope for better LibreOffice in the future. The code seems to be cleaner already, hope the quality of the suite will be also improving in every other aspect.
    Howgh!

    • joelmadero says :

      This is really based on a ton of assumptions that well…many are just not true:
      1) QA wants that task;
      2) QA has the skills for that task;
      3) Volunteers would continue to give their time for free if there were “gate keepers”
      4) This would lead to better results;
      5) QA has enough people to take on such a task

      The best we can hope for is that more users download daily builds and test the features they use. The faster we catch a regression, the more likely it is that it’ll be fixed before release. Furthermore, developers do test their commits a lot (more than our current QA can possibly do on their own), most developers are now doing unit tests, and lastly, there are currently core developers who do review patches before they are submitted and they are more familiar with the code than QA ever will be – so again the realities with >10,000,000 lines of code is that “shit happens” and the best way to get things done is to contribute time, test pre-releases and dailies, and report clean, functional, respectful bug reports.

  5. Ferry says :

    @Joel: I think you are forgetting that users who are taking the time to report bugs are already contributing their time. It’s not really fair to put them in the corner of free riders.

    Likewise, when someone claims (and I have done that too) that a certain bug is preventing their company to upgrade to a newer version, that might very well be justified. Users tend to value certain features of Libreoffice different than developers do. Expressing this is again an important contribution.

    In the past, developers had been considering to remove Base entirely from OpenOffice. That would have been the end of OpenOffice for me. And I’m one of the primary promotors of LibreOffice in our company. Like me, there are hundreds in the same position, but not expressing there priorities.

    In more current versions I rely on Pivot Tables, a feature that seems to be breaking every other release. It’s not that I use that everyday, like writer. More like once a month, but the _importance_ of the work done with that is higher. For a developer who never uses Pivot Tables, wouldn’t knowing that users do use that and take expensive decissions based on the results have value?

    I believe it does.

    I believe, the possibility to express your priorities as a user is one of the important principles of free software,

    I also believe that when users express irritation about regressions, that may be a sign that too little time is being spent on testing – and possibly too much time is being spent on adding new features. Again, for each user complaining there maybe a 100 not complaining. And of that 100 will be a percentage that goes to the control panel and then removes LibreOffice for ever.

    • joelmadero says :

      and this 100% ignores the overall point of the article….

      Comments like this “I also believe that when users express irritation about regressions, that may be a sign that too little time is being spent on testing – and possibly too much time is being spent on adding new features.” are part of the problem. You should rephrase it to say “too little of SOMEONE ELSE’S time is being used….” and thus it goes back to “YOU do the work.” While I agree that taking the time to report a bug is important, it’s in no way the same as someone contributing thousands of hours for free and then feeling disrespected because someone takes 3 minutes to report a bug and half of the bug report is “screaming” about it being a blocker for their BUSINESS – thus suggesting they are making money using the tools that others are creating for free and they expect US to adjust our time to accomodate that….

      Anyways, again I think this 100% misses the point

      • Ferry says :

        3 minutes? I don’t know about others, but when I hit a bug I first think I’m doing something wrong, so retry in other ways, try relinstalling things, search the internet for others with the same problem, then go to file the bug, but first check it’s not already there. Then I try to collect information that I think will be usefull to reproduce the bug, a test document or so. When I check my watch, often half a day has passed. Spending that time is most often rewarding as I find a friendly developer providing a fix before I can blink my eyes, and of course I then spend a bit more time to verify if the fix works or breaks something else.

        Nevertheless, I think that when a 1000 users spend 1 hour of their time that counts the same as when 1 developper spends 1000 hours of his or hers.

        And assuming we all want the same thing, a great product, with great features, that actually work, with a community of happy users and satisfied developers, a screaming user indicates something went wrong – not necessarily with the coding, it could be that the user is confused about who is responsible for what and needs some explanation. And when the problem _is_ with the coding, isn’t it good to know that someone depends on the broken feature? That an entire business depends on it, that won’t upgrade to a new distribution release, because this feature of this application doesn’t work. And as a consequence other broken features of other, less important applications don’t get fixed, because they need to stay with an old release of the distribution (less a problem for Windows users of course).

        Or it could mean that for the project as a whole too little time is spent on testing. Possibly more users need to be involved in testing before things are released. Possibly there could be improvements in the code review process.

        There should of course be no room for disrespect for neither bug reporters nor developpers, but imho there is a lot to learn from an angry user.

  6. Sudhir Khanger says :

    Are you saying you don’t want feedback?

    • joelmadero says :

      No – I’m saying words like “this is a blocker for me isn’t particularly helpful for anyone. Feedback is more than welcome, objective, to the point, etc . . . but subjective and or emotional statements are not particularly useful unless of course that person is willing to get involved and start doing some of the work. It’s amazing how often I see things like “this is basic functionality” – well, that’s incredibly unuseful for anyone. If it’s so basic, and someone thinks it should be implemented, telling others that they should agree that it’s “basic functionality” is again…not useful. I point people to this blog because it lays out the honesty of our project and what users can expect (take it or leave it) and the options available to get whatever pet bug they want taken care of resolved.

      • Sudhir Khanger says :

        I agree we should all stick to reason.

        Although it’s a little unfair to expect every body to contribute via code or design or other technical stuff. Maybe I am one of those guys who helped 5 of my family members move away from Microsoft Office to LibreOffice. Different people contribute in different forms.

        What you are talking about is a cyber bullying problem think about celebs leaks or Gamer Gate. People are in their worse manner on Internet.

  7. joelmadero says :

    Ah – maybe I didn’t make it clear enough. There are about a dozen (haven’t counted exactly) teams on the project, one of them requires coding experience. Getting involved means “doing something” – and what’s great about our community is that when you give time, you earn respect, you make contacts and you can really feel that people are listening (no promises that your pet bug will be fixed still….but it’s a good start to building a community and earning respect from those who do have the talent to fix the 5k+ bugs we currently have on our bug tracker). This is in now ay saying that user feedback isn’t valuable, respected, etc . . . etc . . ., it’s simply saying “complaining is usually not enough” and again, lays out really the four options for those who have pet bugs that they want fixed.

    Jay (one of the commenters) has had tremendous success getting people behind his pet issues (he’s into the toolbar) because he gave a tremendous amount of his time in QA (no dev skills needed), and slowly built up credibility, after talking to a developer, he got the developer interested in his view about how the toolbar should be . . . and well, much of his pet bug/enhancement has now been accomplished.

  8. quixote says :

    I remember back in the old days of OpenOffice as a project at Sun, there was no point saying or asking anything at all. The response was always “You didn’t ask the right way,” “RTFM,” “It’s not a problem on my $24,000 Sun workstation. You should get a real computer.” And so on. So things have improved hugely! 😀

    When people say, “This is a showstopper for me” what they mean is *and anyone with a similar use case*. Presentations bombing in front of a class / city council / boss / conference really are Really Bad for *everybody*. I mean, that’s sort of the whole point of Impress, no? To do presentations in front of groups of people. If that’s not working, it’s not some minor issue.

    (I found the bug report about missing images and the link to this page because I’m trying to troubleshoot exactly this issue for a professor who’s thrown his hands up in despair.)

    Your point that we users need to respect the time and work of the voluteers providing us with this amazing software is exactly right. We should and we do, even if it doesn’t always sound like that when we’re right in the middle of tearing our hair out.

  9. John Smith says :

    Hi, particularly interested in option “3: Pay for a fix (there are companies out there that are really quite fantastic)”. What, exactly, are the companies who are able to code additions to libreoffice for a fee ?

  10. murznn says :

    Thanks for detailed explaination about user bug reporting. The main problem that most of users and even companies are not developers. So they even if strongly want to not be able to write code and submit patches.

    And many of them can’t normally do debug and bibisect.

    But most of bug reporters and subscribers want to see this bug fixed. And not tiny part of them can pay some money for fixing most annoying bugs for him.

    And if some company got the bug, that broke his working processes, it can pay not little money for quick fixing this bug.

    But at now bugs.documentfoundation.org site don’t provide an easy way for pay users to fixing bugs. Most of payable users QA sends to http://www.documentfoundation.org/certification/developers/ page for manual finding developer and contact with them, and on this step often process stops.

    For solve this problem – please integrate some easy donation or deposit paying system into bugs.documentfoundation.org site.

    So popular bugs will got many donations (small from users and large from companies), so 1000 donations of $1 amount got $1000 money for developer that fix this bug.

    This will be good alternative for “vote” functional (that is removed early) and all volunteers will see how much money they got if they fix this bug. It will be very good motivation for all developers to fixing bugs.

    What do you think about this suggestion?

    • joelmadero says :

      If a user takes the time to do this – they are more than free to do so 😉 I have another blog entry about this topic and why TDF will not do it: https://joelmadero.wordpress.com/2014/09/12/why-tdf-doesnt-do-crowd-funding/

      But if a user does it – more power to them. It’d be a tremendous amount of work, a lot of potential legal risk, and probably have some irritated donators along the way 😉 But – I’d fully support the effort by a third party so long as it doesn’t require my time which is already stretched too thin

      • murznn says :

        Thanks for the quick answer! I suggest to not full targeted crowd-funding, I suggest to do easy way for send money (without moneyback) for voting to this bug.

        This money will got Document Foundation organisation like as anonymous donation, but linked with some bug. So if some of volonteers fix this bug, Document Foundation can give to him this money.

        If nobody will fix this bug, this money will stay in Document Foundation organisation.

        So this is classic donation process with some improvements for improve motivation for fixing most annoying bugs.

    • joelmadero says :

      In reply to the last comment – this would have the same issues as the blog says. TDF is not doing targeted funding – period. If a user wants to take this on – more power to them.

      Explicitly: Accounting issues, donor expectations, having less money to do day to day stuff, and lastly (not mentioned in the blog) we’d have to do a tender for each and every one of these. Having written several tenders myself for TDF – this is horribly time consuming and requires work by multiple people within the organization.

      • murznn says :

        I undertand this things, but don’t understand how fixing bug process work now, after disabling vote functional and “confirm too” comments?
        Who decides what bug is more important and must be fixed with high priority in short time?
        Before you can order bugs by votes and at first look at only most voted bugs, not whole long list of all open bugs. But now all bugs are same and you can understand which bug is imortant only via reading full text and produce your own opinion about each bug importance. I think this is not good way.

        For example, if tomorrow I report bug that stops loading libreoffice with some not so specific settings (that covers about 20% of users but they can’t vote or comment “me too”)… Or bug that it stops working with all new Linux kernel versions…

        Who in QA team and how decide that this bug is very important and must be fixed quickly, maybe via money donation to fixer?

        I think that Vote functional needed for all bug systems, because they quickly shows for developers which bugs is more annoying for users. And “donation voting” is improve finances of company, and improve motivation for developers for fixing most voted bugs.

        Alternative like manually findind developer via http://www.documentfoundation.org/certification/developers/ and direct send money to it – too bad way and, I think, will work very bad.

      • murznn says :

        And “donation voting” system you can create without any moneyback option and without guarantee that bug will be fixed. Only for ability to vote and attract attention to bug for users.

      • joelmadero says :

        Please read the post more closely as you are clearly not understanding the point. No one in the project decides the order that bugs get fixed outside of the people actually doing the work. QA doesn’t decide, users don’t decide, the TDF board of directors doesn’t decide. Only those doing the work decide on how and when things get fixed.

        I won’t be responding again – sorry I don’t have the time to go around in circles.

  11. Keith Curtis (@keithccurtis) says :

    LibreOffice needs more money and developers.

    It would be interesting to categorize the most annoying bugs:
    Import / export
    Crashing,
    Display problems
    Base
    Etc.

    It could then be possible to fund people to work on problem areas, like have been done with other tenders.

    I was hoping that one day the Apache team would join in, and some of their people could help with bugs, but it appears most of their people have left.

    You could consider a way to pay for bugfixes. For example, each bugfix is worth $500. After 1 month, it is worth $1000. Even if you did this for the first 100 bugs, it could be an interesting experiment!

    It is frustrating to be in a codebase with few people whose job is to work on the most important issues.

    I hope the fundraising is going well because money is the only way to get people to work on the hardest problems.

    • joelmadero says :

      TDF does not pay for development (generally speaking). That is not the purpose of the foundation – we encourage an environment where entrepreneurs can thrive. Donations go mostly towards infra, staff, and events. At some point I may blog about this a bit more but this idea is incredibly unlikely to happen within TDF.

      • Keith Curtis (@keithccurtis) says :

        It is possible to foster a situation where independent developers and volunteers thrive, while also funding development on important and difficult areas that volunteers aren’t working on today. People would donate more money if they could allocate it for problems they cared about. I realize this is a complicated to implement, but it is worth thinking about while waiting for things to “randomly” get better.

    • Murz says :

      I have found freedomsponsors.org site that already do this thing and have sponsored issues from LibreOffice: https://freedomsponsors.org/search/?project_id=149&operation=SPONSOR

      For example, this issue: https://freedomsponsors.org/issue/158/formatting-feature-request-table-cell-styles-table-styles-writer

      So will be good to add “Sponsor solving this issue” link to this site in Libreoffice bug tracker.

      • joelmadero says :

        Yes FreedomSponsors is an option but we have no control over it so we will not add it to our bug tracker – this wold implicitly say that TDF “supports” FreedomSponsors – which it does not because we don’t control the funds. I have yet to see a freedomsponsor work in our project. Usually the donations are quite small and users are unaware that even the simplest fix can cost thousands and thousands of dollars. That being said, of course people are free to use freedomSponsors to try to get their pet bugs fixed but have to know that there is no guarantees from TDF that the funds will be used in that way.

    • joelmadero says :

      Please read my other post which fully explains why TDF won’t do what you are suggesting. https://joelmadero.wordpress.com/2014/09/12/why-tdf-doesnt-do-crowd-funding/

  12. John Smith says :

    Does the SPI (Software in the Public Interest, http://www.spi-inc.org/ ) do anything like sponsored bug fixing, or even the creation of entire new applications ?

    • joelmadero says :

      You’d have to ask them but my guess is no. They would go through money so fast if it became just a mechanism for people to get pet bugs fixed….even a simple bug can cost thousands of dollars to fix, a more complex one can cost tens or even hundreds of thousands.

      • John Smith says :

        Perhaps ‘professional’ (paid, employed, contractors, etc.) developers (or organizations) would demand such prices, but I doubt that the average open source contributor would ask for hundreds of thousands of dollars for fixing a single bug; after all, they are already fixing bugs (on their own terms, of course) for free ?

    • joelmadero says :

      As I have stated repetitively – TDF is not going to open this door as it brings in a ton of risk and from our analysis not a lot of rewards. But we encourage users (such as yourself) to take the initiative to try these things out and see what results you find.

      For FreedomSponsor I have seen as much as $250 on a bug and not a single developer interested….so I’m not convinced that a developer is going to abandon what interests them (which is what they fix for free) in order to fix a bug for someone else for what amounts to $5/hr or less. But again, no one is stopping our users and/or individual contributors from trying such a setup. It will not have TDF’s official blessing (because of the potential risk involved) but that should not prevent users/contributors who are convinced this will work from trying.

      • John Smith says :

        Receiving $5 an hour for something you’re already doing for free does not seem unreasonable to me 😉 And I’m not saying you or TDF should do this, i’m just curious about what may or may not work; so i’m definitely interested in (the results from) your analysis showing that there are simply not a lot of rewards, and any pointers on setups that might work better.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: