May 21, 2010

That's not what I'm saying

people seem to think that I'm saying support should be a #1 priority. will someone please cite where I said that? yes I said it should be a priority, I said you should do it. I did not say where on the list it should fall. Even if you're an employee at a company making $100k a year, if you're wife is dying, your priority is that, hopefully your children come before said company in most cases too. Understand, that I'm not saying put your software (paid or unpaid) before your life. That would be stupid. I'm saying get this stuff worked into your schedule for working on software. Support is part of the software lifecycle. If you have 2 hours a day to code set some of that aside for support and documentation (pooma number).

Yes, I think I've proven that volunteering to do open source comes with a responsibility or obligation. However, since there is no governing body, and no one has given us rules of good behavior. What that good behavior is, is what is subject to debate.

So hopefully we can stop arguing that we have no responsibility due to being unpaid volunteers and a license, which is really (I believe) just meant to protect us from lawyers. Once we do that we can actually discuss what it is that we actually should consider ourselves responsible for, and more importantly how we can communicate it.

Software licenses is general do not communicate these things. I think David Golden said is on the right track. Keep in mind some Open Source projects (e.g. PostgreSQL discuss a support policy outside of their licensing ) I think postgres policy is excellent for a project of its size. However, I don't expect anyone to support a single release of a small project for 5 years. 1 year might be appropriate for a Major release version.

Actually, PostgreSQL is an exemplary example of how Open Source should be conducted. I've requested stupid features and been told why they were stupid, and no one cried foul of users requesting features. I've asked for help and always received excellent support for my problems. I personally have never been able to locate more than a minute documentation bug in Postgres, and it seems that all new features are adequately documented as part of their QA.

Why is it that we don't all strive for this level of quality?

p.s. the reason postgres created that policy in the first place was that some people started thinking they were supporting old versions (like 7.4) for too long.

UPDATE: I'm locking comments. I'm tired of people commenting when they obviously haven't complete read what I've written. Either that or there grasp of English is poor. It's irritating to be constantly misquoted.

16 comments:

  1. "Yes, I think I've proven that volunteering to do open source comes with a responsibility or obligation."

    I'm not so sure that you've proven this. To use the "volunteer hospital worker" as an example. If the hospital was unhappy with a volunteer they would terminate the use of their services. You have the same choice as the hospital available to you. If you don't like the support you're getting from a project you can stop using it.

    I certainly don't disagree with you that support from the creators or maintainers of a project is a wonderful thing. The absolute nature of your position rubs me the wrong way even just from the consumer side of free software.

    The vibe that I'm getting from your articles is "if you aren't going to support your software, keep it to yourself." If someone actually listens to your advice you are depriving other people of code that may be useful to them.

    "Why is it that we don't all strive for this level of quality?"

    We don't all have the same resources as the PostgreSQL project. A lot of people just scratch a small itch and move on. I might be misunderstanding you but it seems to me that you'd prefer these folks keep their code to themselves. I'd much rather have their code available to me just in case I have a similar itch.

    ReplyDelete
  2. "I'm not so sure that you've proven this. To use the "volunteer hospital worker" as an example. If the hospital was unhappy with a volunteer they would terminate the use of their services. You have the same choice as the hospital available to you. If you don't like the support you're getting from a project you can stop using it."

    your analogy is horrible. That's like saying the patient can fire the hospital employee. Only multideveloper projects can get rid of poor contributers. A single developer project is the same as being self employed. A more correct analogy is I may be able to choose what hospital I go to. That's not true in real life or open source. I may end up having a project on my system because some developer thought it should be used and thus I have it as a dep for some thing that I use.

    I'd prefer they either keep it to themselves or do us a favor and document that they have no intentions of supporting it so that we know. I think a lot less people would use projects if the author wrote "I have no intentions of supporting this going forward".

    yes postgres has a lot of resources. Obviously I don't expect the /same/ level as postgres as I said. Expecting 5 years of support for a small module is ridiculous. Expecting 1 year... not so much. Expecting some basic documentation to be done on new features before a release... that's not so bad. Expecting to get an answer to a bug report, not out of line. At least not in my opinion. also, small 'one off' programs shouldn't need the resources postgres does to support it.

    ReplyDelete
  3. As someone who has contributed very large amounts of code to open source projects and who has maintained even more code for a long time, I can tell you that you're totally off-base. My time is a donation. No more no less. The donation may manifest as code, emails, support on web forums, application of patches, or fixing, rejecting, filing and resolving bug reports. Generally speaking, if you file a (well-formed) bug report against one of my modules, chances are you'll get a helpful answer. But if not, it's your tough luck. Sue me. Alternatively go find somebody you can pay to maintain the software or do it yourself.

    Whatever you think this should work like -- and you're of course entitled to your opinion -- doesn't matter apart from your own contributions in code and maintenance. You can demand all you want. But you still won't be in a position to do so.

    Anybody expecting commercial-grade support from a project that comprises of donated code and donated maintenance time lives in a wildly different world than the rest of us.

    ReplyDelete
  4. "your analogy is horrible. That's like saying the patient can fire the hospital employee."

    I suppose my analogy does not fit perfectly, but analogies rarely do. I was trying to put you in the position of the hospital, not the position of the patient. If we look at it from the perspective you are using the hospital would be a software project, the developer is the employee, and you are the patient. You are free to not use this particular hospital.

    "A more correct analogy is I may be able to choose what hospital I go to. That's not true in real life or open source."

    It may or may not be true in both cases. If you don't like mysql you can choose to use postgres. If there is only one poorly supported application to fit a task I have then I would absolutely prefer to have the option to use it. If it isn't released I don't get this choice.

    "I'd prefer they either keep it to themselves or do us a favor and document that they have no intentions of supporting it so that we know. I think a lot less people would use projects if the author wrote "I have no intentions of supporting this going forward"."

    Why should we assume that a project has a good support infrastructure by default? I don't think it is up to you to dictate how someone who contributes something for free spends there time. It isn't even up to you to dictate how someone who is paid for their contributions spends their time, unless of course you are the one spending the money.

    "Expecting some basic documentation to be done on new features before a release... that's not so bad."

    Then you can be the one who waits for features to be documented. There have been plenty of times that I've been happy to find a barely working, undocumented, bleeding edge feature on many occasions. Why should I have to wait just because you prefer to have documentation first?

    "Expecting to get an answer to a bug report, not out of line. At least not in my opinion."

    Who decides what service level is acceptable? You seem to be advocating that if a project doesn't meet your definition of a minimum service level that they shouldn't bother releasing code.

    I have already said that I agree that the better supported a project is the better. The only thing I don't understand is why you think a project should conform to your standards. No one is forcing you to use any piece of software. There is plenty of choice out there.

    You've done a very good job explaining why documentation and support are very, very important. I agree with this whole heartedly. You have not done a good job at explaining why I should stop releasing unsupported software (assuming that I do, of course!). As far as I can tell I have the choice to release poorly documented, unsupported software. You have a choice to use it or ignore it.

    If you don't have the choice to ignore it (in your dependency example above) then your beef shouldn't be with me. It should probably be somewhere upstream of me :)

    ReplyDelete
  5. @tsee where did I say I expect 'commercial grade' WHERE? HUH? you people need to READ what I SAID and STOP reading INTO it. (note: I suppose someone will say this is what I've done with "patches welcome" reading into what other people have said.

    ReplyDelete
  6. @Pat ever had to go to the ER in an ambulance? did they ask you which hospital you wanted to go to? I've also known people who got flown from one hospital to another. You don't always get to choose your hospital, or your software. sometimes someone else makes that choice and you have to live with it.

    ReplyDelete
  7. I've already stated that the discrepancy here is on what level of responsibility we should take. I don't actually expect that everyone will agree with my level of responsibility. On the other hand I think if I've convinced even 1 person that it's better to write documentation and attempt to provide reasonable support (reasonable on both ends) then I've improved the market.

    Of course it's very hard to convince anybody with people constantly putting words in my mouth. Or making imbecilic counterarguments that are neither here nor there.

    ReplyDelete
  8. I am not yet convinced that what I've said is unreasonable. I'm only convinced that people only think of themselves.

    ReplyDelete
  9. Where do you document your exact support policy (as you suggest people should document theirs) in the two modules you have on CPAN? I couldn't find it in README, LICENSE or POD.

    ReplyDelete
  10. @tsee the only reference I have so far is to an off rt bugtracker. but I was thinking about that exact problem before I posted this today. dagolden's post made me think more on exactly the problem is. Most people are coming back saying they aren't interested in supporting anything. But you'll note that's not what dagolden's post says.

    I'm thinking about building a module like Software::License that allows people to more easily and standardly define what their support level actually is.

    I try to put my money where my mouth is. but sometimes my mouth says things before the money is there ;) . I'm working on it. However, I am trying to otherwise comply with everything else I've said. Such as making sure I've provided good documentation, and I will respond to requests on github within a reasonable amount of time. Heck, if you want to use T-SSS in Catalyst I'll help you get that working even though it's not supported.

    ReplyDelete
  11. "@Pat ever had to go to the ER in an ambulance? did they ask you which hospital you wanted to go to? I've also known people who got flown from one hospital to another."

    Yes, I've had similar experiences. Thankfully this is only an analogy.

    "You don't always get to choose your hospital, or your software. sometimes someone else makes that choice and you have to live with it."

    Thankfully, I always get to choose my own software. If you don't then you should complain to the people who made the software choices you dislike instead of belittling the people who are offering software to others.

    "you people need to READ what I SAID and STOP reading INTO it."

    I'd appreciate it if you'd respond to the most important part of my comments:

    "If you don't like the support you're getting from a project you can stop using it."

    and

    "As far as I can tell I have the choice to release poorly documented, unsupported software. You have a choice to use it or ignore it."

    Your whole series of blog posts fails to explain why your problem should be dealt with by the producer of the software and not the consumer. The only reason that I recall you stating is that sometimes the choice of software isn't yours to make.

    If that is the case I don't understand why the fault is with the developer. I can do a very poor job of bringing this back to the hospital analogy and say that you are angry with the hospital (aka software project) because your insurance provider (aka the person who chose your software) won't pay to let you go to a different hospital.

    I really don't mean to sound angry about this, if I do. I, and probably many others, feel like you are not only ungrateful of the free work we have done but you sound as though you are pissed off that we even bothered to contribute anything.

    ReplyDelete
  12. "I really don't mean to sound angry about this, if I do. I, and probably many others, feel like you are not only ungrateful of the free work we have done but you sound as though you are pissed off that we even bothered to contribute anything."

    This is what I mean by putting words in my mouth. I'm angry at the attitude I get when I request help for undocumented procedures. I go to RTFM and there's nothing in it (that's useful) I ask for help and I get "patches welcome". how can I write a documentation patch for it? I don't know how to do it. "Go read the code"... What code? which part. I'm admittedly a novice at code reading (and writing) I can use a well documented library. I can improve existing documentation. But I can't do anything with nothing I can understand. This is the same story I've been getting for 7 years. Only in this last year has "go read the code" become remotely feasible, and even now it isn't really. plus I don't think anyone should have to read the code to figure out a basic api.

    You are very lucky to work for yourself. I assume you must, because otherwise you'd almost certainly occasionally have to use software you didn't pick.

    ReplyDelete
  13. "This is what I mean by putting words in my mouth."

    I don't think I'm putting words in your mouth. The words you choose paint a picture in my head. The picture I'm getting is that you're angry that someone would spend time to release software that isn't up to your specifications. You're the one who said that if its not documented it shouldn't be released at all. :)

    "I'm angry at the attitude I get when I request help for undocumented procedures."

    It's been pointed out to you that what you perceive as a bad attitude may very well not be intended. I make no claim in either direction, I certainly don't have enough information.

    "how can I write a documentation patch for it? I don't know how to do it."

    I can't speak for anyone who has said this to you, I can only attempt to guess at the meaning. If something is undocumented and you figure out how to make it work you can certainly contribute documentation back to a project. The author used his resources to create the application. You'd be using your resources to figure out how to make it work the way you need it and documenting how you did it. It's a different kind of work but it is very important. It's also voluntary, you don't have to do it.

    ""Go read the code"... What code? which part. I'm admittedly a novice at code reading (and writing) I can use a well documented library. I can improve existing documentation. But I can't do anything with nothing I can understand."

    At this point I would guess that you aren't the target audience of the author of the project. There's nothing wrong with that. It isn't his fault that you didn't have the skill set to do what you needed to do. I would bet that he's more motivated to get the software working so that he can use it than he to write documentation so that you can use it.

    "This is the same story I've been getting for 7 years. Only in this last year has "go read the code" become remotely feasible, and even now it isn't really. plus I don't think anyone should have to read the code to figure out a basic api."

    Well documented projects are more likely to prosper. It is difficult to talk about generalities regarding this topic. For the most part I've always had very good luck the open source software I have used.

    "You are very lucky to work for yourself. I assume you must, because otherwise you'd almost certainly occasionally have to use software you didn't pick."

    You don't have to work for yourself to be in a position to chose your software. I just feel you should be directing your unhappiness towards the powers that are choosing the problem software.

    I agree that everything you want would be nice. I just don't feel that the consumer has the right to dictate what the producer does with his resources.

    Your issues need to be resolved on the consumer side. I don't want your rules to cause software that I need to not be released any more than I'd want the government telling me I can't play Grand Theft Auto. If you don't want to play GTA then just don't buy it :).

    Freedom is supposed to be there for the users and the developers.

    ReplyDelete
  14. I would like to point out that I differentiate between 'release' and shared. I have no problems with people putting undocumented code up in repositories and 'prereleases'

    ReplyDelete
  15. "I would like to point out that I differentiate between 'release' and shared. I have no problems with people putting undocumented code up in repositories and 'prereleases' "

    And that is what frankly makes you a entitled, whiny little bitch. Yes I got insulting. How dare you say you've proven I am obliged to give you support? I am obliged to nothing. Also, you simply don't have a say over what people can release and what they can't.

    Grow up, grow a pair, grow whatever you need to understand that. This is free software without warranty. I owe you nothing other than what I already provided you with. If you have a problem with that, maybe you shouldn't use the software you're given without charge.

    Personally I hope not a single developer changes his mind about releasing undocumented software. It has helped me a lot time and time again. Just because you'd be less frustrated with no solution at all than an undocumented one, doesn't mean the rest of the world has to follow.

    I think I've just proven that while you started out with a normal concern, now you're only after convincing people that you're right. I've also proven time and time again that you value your own time higher than mine or any oder developers that have given you this software for free. It was also successfully proven that your entitled attitude is exactly the problem.

    ReplyDelete
  16. This comment has been removed by the author.

    ReplyDelete