5 ms·

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 s

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.
- sjs 17y ago
  Most open-source projects fall into the category "I wrote this and thought it was cool/useful, if you do too you're welcome to use it".
- algorias 17y ago
  You're right that there needs to be a distinction between community projects and loose pieces of code. They're completely different in nature, and that's why it's so important to make clear which is which.
ZachPruckowski 17y ago
I don't think that's fair. I think "when you SELL code", there's an implicit (and usually explicit) commitment to improve/maintain it, but not when you give it away. When someone buys me a Christmas present, I don't go to them to repair it if it malfunctions. Besides, the Markdown license explicitly says it's "as is" with no such support promises. I don't think you can even call Markdown users Gruber's userbase. He created Markdown because it works for him. If you don't like how it works, change it and call it something else (MarkSide? MarkIn? MarkOut?)
nostrademons 17y ago
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/ 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 improving JQuery?
- algorias 17y ago
  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 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.
  - nostrademons 17y ago
    You don't know what's an experiment and what's a massively successful library until you release it. JQuery was initially intended to be the experiment; presumably he had other projects he was working on at the time that were supposed to be his "real" work. 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.

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.

sjs 17y ago
Most open-source projects fall into the category "I wrote this and thought it was cool/useful, if you do too you're welcome to use it".
algorias 17y ago
You're right that there needs to be a distinction between community projects and loose pieces of code. They're completely different in nature, and that's why it's so important to make clear which is which.

ZachPruckowski 17y ago

I don't think that's fair. I think "when you SELL code", there's an implicit (and usually explicit) commitment to improve/maintain it, but not when you give it away. When someone buys me a Christmas present, I don't go to them to repair it if it malfunctions. Besides, the Markdown license explicitly says it's "as is" with no such support promises. I don't think you can even call Markdown users Gruber's userbase. He created Markdown because it works for him. If you don't like how it works, change it and call it something else (MarkSide? MarkIn? MarkOut?)

nostrademons 17y ago

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/ 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 improving JQuery?

algorias 17y ago
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 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.
- nostrademons 17y ago
  You don't know what's an experiment and what's a massively successful library until you release it. JQuery was initially intended to be the experiment; presumably he had other projects he was working on at the time that were supposed to be his "real" work. 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.