61–70 of 75 posts
Markdown is not John Gruber's baby, it is an open source project. Stop anthropomorphizing everything in order to make a cheap point.
It's absolutely his buggy baby.
Atwood's blog post is an example of why I sometimes say that the main point of inventing "open source" was to turn the free software movement into the gratis labor movement. Atwood's account of history here is misleading, judging by the mailing list he quotes. He is unfair to accuse Gruber of being "passive aggressive". I'll talk at the end about why the accusation is part of the gratis labor movement. The discussion…
> From that, Atwood somehow gets "passive aggressive". That confused me too. Exactly how is "I despise what you've done with Text::Markdown" passive?
Earlier quoted context omitted.
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…
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 long…
Earlier quoted context omitted.
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…
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 long…
Earlier quoted context omitted.
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…
> 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.
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.
Earlier quoted context omitted.
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…
If everyone thought this way, many really great projects would never have been started, because their authors would be so bogged down by maintenance work they'd never do anything new. Take a look at John Resig's projects page: http://ejohn.org/projects/ Click on anything that's not a JavaScript project, and you get a broken link. Would you rather he spend time fixing them up, or would you rather he spend time improvi…
It's great that this guy works on JQuery, but I think the minimum that should be expected is to properly tie up loose ends: Fix broken links, make sure it's clearly stated that the code in question is considered done (feature complete, unmaintained, etc). Officially hand it off to someone else if possible.
Earlier quoted context omitted.
If everyone thought this way, many really great projects would never have been started, because their authors would be so bogged down by maintenance work they'd never do anything new. Take a look at John Resig's projects page: http://ejohn.org/projects/ Click on anything that's not a JavaScript project, and you get a broken link. Would you rather he spend time fixing them up, or would you rather he spend time improvi…
If your code is meant to be an experiment, a headstart for someone else to build on, then that needs to be explicit. There's enough open source code out there. The problem is quality. All projects that are making an impact are doing so because they are actively backed and developed. It's great that this guy works on JQuery, but I think the minimum that should be expected is to properly tie up loose ends: Fix broken l…
There're a bunch of counterexamples to the "all projects that are making an impact are doing so because they are actively backed and developed." Markdown is one obvious one. The Internet Explorer team was disbanded from 2002-2005, even though it was the most popular browser on the market. Several Google projects that are used by millions of people a day are completely de-staffed.
And there are many more projects that are actively backed and developed and yet are not making an impact. We'd be much better off if their developers quit what they were doing and found something else to do.
Earlier quoted context omitted.
I agree. I don't see why Jeff didn't just start a GitHub project himself as a new starting point for the community.
Um, he pretty much did that: 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
Earlier quoted context omitted.
Um, he pretty much did that: 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
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.
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?..."
This isn't directly relevant, but if you use Markdown a lot, I highly recommend David Parson's Discount (a Markdown implementation in C). (Parsons is also active on the Markdown mail list, which is helpful.) http://www.pell.portland.or.us/~orc/Code/discount/
I'll put in a plug for Pandoc here: http://johnmacfarlane.net/pandoc/ It's written in Haskell, it uses a real parser, it fixes several bugs in the spec, and it can output to nearly any format imaginable. What else could you want?
http://github.com/toyvo/libpandoc
"a build configuration for Pandoc that produces a standalone C-callable system library"