5 ms·

Not to be too harsh on Jeff Atwood - as he has decades more experience than myself. But does anyone else feel that this blog post is a bit out of line? In shor

by ElliotH 17y ago

Not to be too harsh on Jeff Atwood - as he has decades more experience than myself. But does anyone else feel that this blog post is a bit out of line? In short when John Gruber gives the code out under a BSD thatis a gift to whoever wants to use it - and it gives them near-complete freedom to use Markdown however they like. I don't see why on top of this gift he is in any way obliged to provide 'leadership' or 'direction'. I don't really see why its even required. Anybody can feel free to come in, fork the project with their own modifications - and if its popular then they can be the leader or their fork.

rubyrescue 17y ago
You're not being too harsh. Atwood's decades of experience is no excuse for what is essentially a personal attack, nor should it be a defense when you call him on it.
andreyf 17y ago
Not harsh at all. IMO, the kind of attitude that equates the responsibility to maintain your open source projects to the parenting of a child is one thing which scares people from contributing to the open source community.
apinstein 17y ago
I agree. I don't see why Jeff didn't just start a GitHub project himself as a new starting point for the community.
- rapind 17y ago
  My guess is that this article is a precursor to doing just that. I expect an announcement from Jeff pretty soon about a new markdown project on Github. I don't agree with his point of view in this article, however it does sound like he knows the project pretty well and would be suited to getting it rolling again.
  - StrawberryFrog 17y ago
    It's over here: http://code.google.com/p/markdownsharp/ http://code.google.com/p/markdownsharp/
- StrawberryFrog 17y ago
  Um, he pretty much did that: http://code.google.com/p/markdownsharp/ http://code.google.com/p/markdownsharp/ By the way, what's with the assumption that github is the one true way? Is it that much better for you? I have code on Github, SourceForge, google code and while Github has some UI goodess, the windows tools for it are quite raw. The others also work fine. If you like DVCS, Sourceforge and Google code both do Mercurial
  - pwim 17y ago
    Github's strength is that it allows for incredibly easy collaboration. If you want to make a change to any open source project, you just need to fork it, make changes in your copy, and send a pull request to the original author. Neither Google code nor SourceForge offers such a simple contribution mechanism.
    - pohl 17y ago
      I haven't participated in any Github projects yet, so forgive me if I'm missing something, but isn't what you're describing a part of DVCS (Distributed Version Control Systems) in general, and not Git per se? (and, least of all, GitHub?) Couldn't one do what you're describing with a Google Code project that uses Mercurial? Or at bitbucket.org using Mercurial? Or at launchpad.net using Bazaar? I don't think StrawberryFrog's question has been adequately answered: "what's with the assumption that github is the one true way?..."
      - pjhyett 17y ago
        I don't think anyone said GitHub is "the one true way". I think you'll find more and more people putting code on GitHub, because of the general uptick in contributions when code is hosted there. (disclosure: I work for GitHub)
        pohl 17y ago
        I don't think anyone said GitHub is "the one true way". I'm pretty sure the question was meant a bit more loosely, not as a direct challenge to someone's post here, but to the general prevalence of a meme that roughly fits that description. I certainly wouldn't suggest grepping for that phrase as a method of getting a feel for its virulence out "in the wild". Instead, look or tacit assumptions, misattribution's of value, and conspicuous omission of alternatives. I guess good, old-fashioned "reading between the lines" is what I'm suggesting. A pretty dramatic illustration popped up on my RSS reader this morning. Someone submitted a HN article with the title "Jeff Atwood's open source contributions", which was nothing but a link to http://github.com/codinghorror http://github.com/codinghorror - which currently shows zero projects. It was quickly flagged here at HN, but it lives on over at Reddit. http://news.ycombinator.com/item?id=1023696 http://news.ycombinator.com/item?id=1023696 The tacit assumption here is that if Jeff has zero repositories at GitHub, then he has made zero open source code contributions. I don't mean to detract from how cool it is that your product is so successful. (Kudos!) But its fans often have a creepy blind spot to alternatives, in my opinion.
algorias 17y ago
When you release code, there's an implicit commitment of improving and maintaining it, or at least finding someone who will when you can't anymore, unless you say otherwise from the start. The attention and effort others invest in your project needs to be respected. You do have an ethical obligation to follow through on the project, at least in my view. Feeling no obligation towards your user base just because one of the price dimensions (money) happens to be 0 is an irresponsible attitude.
- nollidge 17y ago
  > When you release code, there's an implicit commitment of improving and maintaining it Why? Why are there any commitments whatsoever attached to making code publicly available? I could just as easily keep it to myself.
  - algorias 17y ago
    If you say you'll help someone out, then you better show up. Otherwise, you'll leave the other guy worse off than if you hadn't offered to help in the first place. So, yes, it is better to release nothing than something buggy and unsupported. The former doesn't waste everyone's time pretending to be a solution.
    - thejake 17y ago
      What an entitled attitude.
- slavingia 17y ago
  I disagree. When you release code, you release code. Improvement and maintenance are not things that you imply you'll give. Especially under a BSD license. If you gift someone a laptop, you're not bound to help them with every problem they encounter.
- boucher 17y ago
  Have to disagree. Releasing code doesn't imply any obligation to that code. If it did, the volume of open source code out there would be a fraction of what it is right now. People are constantly changing directions, and constantly trying out new things which may or may not be useful to them in the future. We're all better off if that code gets released. In turn, we can't expect people to support code they may no longer use, or may not have ever really cared about in the first place. It should be clear that running an open source project is something completely different. If you make an attempt to start a community, you probably should keep up with that community, or at least responsibly exit it. But people usually build communities around things that are really important to them, or that they have an ulterior motive for advocating (not necessarily a bad motive, just one beyond pure open source). From where I'm sitting, if Gruber isn't adding anything to the community, he should have been made irrelevant by that community.
nickelplate 17y ago
"as he has decades more experience than myself" Decades? I doubt that. And no, you're not being too harsh. In fact, I think you might be too kind.
- deleted 17y ago
  [deleted]
joeyh 17y ago
If Gruber had released markdown and explicitly walked away from it, then yes, we would only be justified in appreciating his gift. (And I think anyone seriously using markdown has to conclude he did essentially release and walk away from the perl implementation. Aside from it being 6 to 12 times faster, there is no reason now to use it rather than the Text::MarkDown in CPAN -- which fixes its many, many, crippling bugs and maintains perfect compatability.) However, somehow or other, we've gotten the idea that Gruber is responsible for at least the ongoing development of the spec. Atwood excerpts a recent mail from Gruber where he's clearly still trying to do that. I sorta get the impression Gruber wants to keep the markdown spec exactly as it is, although the last time he surfaced on mailing list it was to say that a proposed addition looked like a (rare) good idea. At least the internal underlines issue makes markdown a real PITA to use for any technical writing, and really needs to be fixed in the spec. The URL thing is debatable; while Atwood's newline suggestion misses the point of markdown. The risk is clearly that markdown will fragment with different sites handling these issues differently. There are many better ways to manage specs than what Gruber is doing.
- joeyh 17y ago
  Correction: Text::MarkDown differs in compatability in that it _seems_ to fix the internal underline issue. Although possibly not completly.

by ElliotH 17y ago

rubyrescue 17y ago

You're not being too harsh. Atwood's decades of experience is no excuse for what is essentially a personal attack, nor should it be a defense when you call him on it.

andreyf 17y ago

Not harsh at all. IMO, the kind of attitude that equates the responsibility to maintain your open source projects to the parenting of a child is one thing which scares people from contributing to the open source community.

apinstein 17y ago

I agree. I don't see why Jeff didn't just start a GitHub project himself as a new starting point for the community.

rapind 17y ago
My guess is that this article is a precursor to doing just that. I expect an announcement from Jeff pretty soon about a new markdown project on Github. I don't agree with his point of view in this article, however it does sound like he knows the project pretty well and would be suited to getting it rolling again.
- StrawberryFrog 17y ago
  It's over here: http://code.google.com/p/markdownsharp/ http://code.google.com/p/markdownsharp/
StrawberryFrog 17y ago
Um, he pretty much did that: http://code.google.com/p/markdownsharp/ http://code.google.com/p/markdownsharp/ By the way, what's with the assumption that github is the one true way? Is it that much better for you? I have code on Github, SourceForge, google code and while Github has some UI goodess, the windows tools for it are quite raw. The others also work fine. If you like DVCS, Sourceforge and Google code both do Mercurial
- pwim 17y ago
  Github's strength is that it allows for incredibly easy collaboration. If you want to make a change to any open source project, you just need to fork it, make changes in your copy, and send a pull request to the original author. Neither Google code nor SourceForge offers such a simple contribution mechanism.
  - pohl 17y ago
    I haven't participated in any Github projects yet, so forgive me if I'm missing something, but isn't what you're describing a part of DVCS (Distributed Version Control Systems) in general, and not Git per se? (and, least of all, GitHub?) Couldn't one do what you're describing with a Google Code project that uses Mercurial? Or at bitbucket.org using Mercurial? Or at launchpad.net using Bazaar? I don't think StrawberryFrog's question has been adequately answered: "what's with the assumption that github is the one true way?..."
    - pjhyett 17y ago
      I don't think anyone said GitHub is "the one true way". I think you'll find more and more people putting code on GitHub, because of the general uptick in contributions when code is hosted there. (disclosure: I work for GitHub)
      - pohl 17y ago
        I don't think anyone said GitHub is "the one true way". I'm pretty sure the question was meant a bit more loosely, not as a direct challenge to someone's post here, but to the general prevalence of a meme that roughly fits that description. I certainly wouldn't suggest grepping for that phrase as a method of getting a feel for its virulence out "in the wild". Instead, look or tacit assumptions, misattribution's of value, and conspicuous omission of alternatives. I guess good, old-fashioned "reading between the lines" is what I'm suggesting. A pretty dramatic illustration popped up on my RSS reader this morning. Someone submitted a HN article with the title "Jeff Atwood's open source contributions", which was nothing but a link to http://github.com/codinghorror http://github.com/codinghorror - which currently shows zero projects. It was quickly flagged here at HN, but it lives on over at Reddit. http://news.ycombinator.com/item?id=1023696 http://news.ycombinator.com/item?id=1023696 The tacit assumption here is that if Jeff has zero repositories at GitHub, then he has made zero open source code contributions. I don't mean to detract from how cool it is that your product is so successful. (Kudos!) But its fans often have a creepy blind spot to alternatives, in my opinion.

algorias 17y ago

When you release code, there's an implicit commitment of improving and maintaining it, or at least finding someone who will when you can't anymore, unless you say otherwise from the start. The attention and effort others invest in your project needs to be respected. You do have an ethical obligation to follow through on the project, at least in my view. Feeling no obligation towards your user base just because one of the price dimensions (money) happens to be 0 is an irresponsible attitude.

nollidge 17y ago
> When you release code, there's an implicit commitment of improving and maintaining it Why? Why are there any commitments whatsoever attached to making code publicly available? I could just as easily keep it to myself.
- algorias 17y ago
  If you say you'll help someone out, then you better show up. Otherwise, you'll leave the other guy worse off than if you hadn't offered to help in the first place. So, yes, it is better to release nothing than something buggy and unsupported. The former doesn't waste everyone's time pretending to be a solution.
  - thejake 17y ago
    What an entitled attitude.
slavingia 17y ago
I disagree. When you release code, you release code. Improvement and maintenance are not things that you imply you'll give. Especially under a BSD license. If you gift someone a laptop, you're not bound to help them with every problem they encounter.
boucher 17y ago
Have to disagree. Releasing code doesn't imply any obligation to that code. If it did, the volume of open source code out there would be a fraction of what it is right now. People are constantly changing directions, and constantly trying out new things which may or may not be useful to them in the future. We're all better off if that code gets released. In turn, we can't expect people to support code they may no longer use, or may not have ever really cared about in the first place. It should be clear that running an open source project is something completely different. If you make an attempt to start a community, you probably should keep up with that community, or at least responsibly exit it. But people usually build communities around things that are really important to them, or that they have an ulterior motive for advocating (not necessarily a bad motive, just one beyond pure open source). From where I'm sitting, if Gruber isn't adding anything to the community, he should have been made irrelevant by that community.

nickelplate 17y ago

"as he has decades more experience than myself" Decades? I doubt that. And no, you're not being too harsh. In fact, I think you might be too kind.

deleted 17y ago
[deleted]

joeyh 17y ago

If Gruber had released markdown and explicitly walked away from it, then yes, we would only be justified in appreciating his gift. (And I think anyone seriously using markdown has to conclude he did essentially release and walk away from the perl implementation. Aside from it being 6 to 12 times faster, there is no reason now to use it rather than the Text::MarkDown in CPAN -- which fixes its many, many, crippling bugs and maintains perfect compatability.) However, somehow or other, we've gotten the idea that Gruber is responsible for at least the ongoing development of the spec. Atwood excerpts a recent mail from Gruber where he's clearly still trying to do that. I sorta get the impression Gruber wants to keep the markdown spec exactly as it is, although the last time he surfaced on mailing list it was to say that a proposed addition looked like a (rare) good idea. At least the internal underlines issue makes markdown a real PITA to use for any technical writing, and really needs to be fixed in the spec. The URL thing is debatable; while Atwood's newline suggestion misses the point of markdown. The risk is clearly that markdown will fragment with different sites handling these issues differently. There are many better ways to manage specs than what Gruber is doing.

joeyh 17y ago
Correction: Text::MarkDown differs in compatability in that it _seems_ to fix the internal underline issue. Although possibly not completly.