Open Source and Saying “No”
connortumbleson.com
Open Source and Saying “No”
1–10 of 143 posts
Re: Open Source and Saying “No”
#2[deleted]
Re: Open Source and Saying “No”
#3Doing exactly the opposite is also a right approach:
Absorb as many features as possible, so that more people will be gravitated into a centralized place. For bugs, if the original feature submitter isn't around, potential new maintainers will emerge and fix them.
Re: Open Source and Saying “No”
#4Doing exactly the opposite is also a right approach: Absorb as many features as possible, so that more people will be gravitated into a centralized place. For bugs, if the original feature submitter isn't around, potential new maintainers will emerge and fix them.
That’s very idealistic and unfortunately life is far from ideal. Its better to do one thing very well than to do many things badly.
Re: Open Source and Saying “No”
#5Doing exactly the opposite is also a right approach: Absorb as many features as possible, so that more people will be gravitated into a centralized place. For bugs, if the original feature submitter isn't around, potential new maintainers will emerge and fix them.
This only works for few high profile projects.
Most projects developed this way die of development resources starvation. Once you have added all those features you will face all the consequences of developing a complex system -- difficulty to get anything done, new devs requiring substantial amount of time to get started, people getting discouraged quickly, etc. As you add complexity, the ways users use your platform will grow exponentially -- potentially causing an explosion of bugs.
I don't mean users using your platform in many different ways is bad, the question is "Can you support it?"
If you run into developer resource starvation users will find that you are making no progress and will find an alternative and this will make your project even less enticing for contributors. This is how a project dies.
If you are single developer and want to do something useful for community your best shot is to make something simple and add things judiciously.
So how do large open source projects survive and how are they different? The issue is that when it comes to contributors, relatively few large projects receive most of the contributions. Everybody wants to contribute to something well known, high profile, used by a lot of people. Not many developers want to make it their mission to support a useful but an obscure plugin to something else.
Re: Open Source and Saying “No”
#6Doing exactly the opposite is also a right approach: Absorb as many features as possible, so that more people will be gravitated into a centralized place. For bugs, if the original feature submitter isn't around, potential new maintainers will emerge and fix them.
I'd say precedent is against you here. There's many examples of widely used open source projects that don't get lots of free maintenance effort.
Maintaining something well is hard and requires commitment, you can't just crowd source it with people dipping in and out with the occasional fix and new feature. Being careful about what PRs you accept, especially when it's a big new feature is crucial to the health of an open source project and the mental health of its maintainers.
Re: Open Source and Saying “No”
#7Doing exactly the opposite is also a right approach: Absorb as many features as possible, so that more people will be gravitated into a centralized place. For bugs, if the original feature submitter isn't around, potential new maintainers will emerge and fix them.
[deleted]
Re: Open Source and Saying “No”
#8Doing exactly the opposite is also a right approach: Absorb as many features as possible, so that more people will be gravitated into a centralized place. For bugs, if the original feature submitter isn't around, potential new maintainers will emerge and fix them.
>Projects should do exactly the opposite:
This may work as a strategy for a VC-backed startup, where you just throw money into resources to create the largest possible gravity for your product, and solve the technical debt by growing your team once you have a critical (paying) userbase.
But how would this work when there's no money to throw around, your product is free and every contributor is actually a volunteer who still needs to earn his living elsewhere?
Re: Open Source and Saying “No”
#9I maintain python sysrsync package and my idea at first was to validate files before syncing with systems rsync. That was rightly pointed out by users as bloat and I took it off in a major release.
Similarly there is a feature request that although justified for the sake of symmetry (I support exclude in the API but not include) I am reluctant to add it because I really don't want it to have more features, when there is a way to access all rsync flags using options argument.
Re: Open Source and Saying “No”
#10Doing exactly the opposite is also a right approach: Absorb as many features as possible, so that more people will be gravitated into a centralized place. For bugs, if the original feature submitter isn't around, potential new maintainers will emerge and fix them.
Making this will exponentially increase the glue code required to tie everything together.
So, while new developers fix the features, they'll also need to fix that glue layer too, making the work twice or thrice as big. Also things will also even get more complicated as long as things get added into the mix.
This is why UNIX philosophy is very important. Keeps software simple, compact and much more easier to maintain.