Interesting idea. But you’re missing a couple of major drawbacks:
Software is usually a liability rather than an asset. It can increase your attack surface. It can be a time sink to maintain over time. It can not quite do what you want and bleed energy. It can be actively malicious, insidiously stealing your data or bitcoin. (I’m seeing a lot more awareness of these issues after the security vulnerabilities and Cambridge Analytica of the last few years. For example, this article can be distilled down to, “stop using software to trust people, software will never be trustworthy enough.” Software’s benefits are usually residents of Mediocristan, but its drawbacks often live in Extremistan.)
Dependencies matter. You list as an advantage that “Unless the language or library used is part of the requirements, programmers proficient in different languages can still trade.” But you’re reading that fact from exactly the wrong direction. Since anything I’m unable to get running is by definition useless, and since installing languages and libraries is non-trivial in the most general case, platform dependencies will grow to become an essential part of requirements. An obvious example: any programs I distribute are useless to someone running Windows. Another example: If I don’t want to install Java, you either don’t use Java, or you need to come up with a way to distribute your program with Java in some sandboxed fashion. (We all know how successful such attempts have been.)
With these issues in mind, I have two suggestions.
Suggestion #1: Reduce the unit of exchange. If people exchanged programs that could be built in an hour or two rather than a week or two, the programs would be more obviously right, more generally useful and easier to specify, detect duplicates, probably rely on fewer dependencies, have smaller risks for the author, etc., etc.
If the expected project size were to go down I can contribute a couple of small scripts I’ve built that I find very useful:
search: looks in a unix-like directory tree for files containing all of a list of terms. Basically a search-engine-like interface atop grep. Useful for maildirs, but since I started using it I’ve also started structuring other data sources as directories with one file per unit.
accumulate: an add-on for search above that allows me to try multiple searches when looking for something specific, without getting duplicate results on successive searches.
(Hmm, as I look at these I notice a couple more drawbacks to your idea: 3. Many programs are demand-creating rather than demand-satisfying. People may not know they want them until they see them in action. 4. Programs often work in systems. Unix pipes. Or operating on a directory of files with one file per unit, as I do above. Or pipes operating on Yaml. Individual programs in these sets aren’t useful without the right context and environment.)
Suggestion #2: Cater to a more specific kind of person. I can imagine at least two axes to segment programmers by: time rich vs time poor and money rich vs money poor. So for example someone money rich but time poor and someone time rich but money poor would end up transacting the conventional job for money. Your current approach has benefits along both time and money axes, but the cost is the drawbacks enumerated above. For example, I’m not particularly time rich, but I know that a program I write will do just what I want, nothing I don’t want, be fairly parsimonious of dependencies, and set at least some sort of lower bound for secure practices. So if I have an idea for a program it’s better to wait and build it myself rather than try to optimize too hard for time. But maybe there’s some way to mitigate the drawbacks if you focus on just one of the quadrants?
I think you are mainly thinking of software that will be used on servers open to the internet and when I wrote this, I was mainly thinking of desktop apps used to make things (which may then be put on Internet-facing servers in production, but not the desktop app itself).
But aren’t these general problems with using open source libraries in your projects (and not something specific to trades)?
For the potentially malicious versions, shouldn’t having the source code at least help quite a bit in that direction.
Depending on how bad it is, I’d argue that you didn’t actually get the software you wanted if it ends up being so much trouble. (And consequently shouldn’t be used despite another user having made it, which is unfortunate but avoids the downsides.)
I’d say this would all just go into the requirements. I’m hope there’s similar enough requirements that they would center around major platforms (that makes matches easier), which is still less restrictive than a specific language or library.
Maybe I just happen to make stuff that’s more cross platform by default.
Since anything I’m unable to get running is by definition useless,
See the “usage” pattern I described. In my case, not being able to run it would still lose a lot of value, isn’t useless.
Suggestion #1: I’m happy to try this version if there’s enough people.
Though I don’t think I have anything I could safely say can be made in 1-2 hours from scratch. Any random hiccup can take up the entire time. It also makes thinking about and writing out the specs a bit less worthwhile.
But I don’t know. “A weekend” wasn’t that thought out of a time length either. So I’d give this one a go if more people prefer it.
If the expected project size were to go down I can contribute a couple of small scripts I’ve built that I find very useful:
I hadn’t thought of just releasing existing source. But that works too! Really any way works, even finding an existing project (if licenced right).
You still have to add programs that you want. And the way I described it, it could be that someone else is assigned to make search and accumulate (which you already have) while you’re assigned something else from your list.
People may not know they want them until they see them in action.
I guess people can browse the existing list, although this doensn’t help see it in action. I was thinking more of programs that do not yet exist so you couldn’t see them in action anyways.
Suggestion #2 This is an interesting suggestion but I didn’t entirely follow your discussion.
How would focusing on only one quadrant (potentially) help with the drawbacks listed? Do you mean all the time poor, money right would tend to want the same kind of things?
Or do you mean some of the quadrants wouldn’t find the drawbacks as much?
(I’m in no way in disagreement, just didn’t follow the reasoning entirely.)
Yes, you’re right that my drawbacks apply as well to existing open source. But you’re proposing something new, something where people’s reputations aren’t involved yet the way they’re involved in conventional projects. And something where I have to precommit to using something that doesn’t exist yet. The competition isn’t existing open source projects. The competition is me making something myself.
(I’m trying to attack these drawbacks for open source as well.)
See the “usage” pattern I described. In my case, not being able to run it would still lose a lot of value, isn’t useless.
I don’t follow. I don’t see the word “usage” anywhere in OP.
Maybe I just happen to make stuff that’s more cross platform by default.
What sort of stack do you use? How do you test on multiple platforms?
Thanks again for your thoughts. I have to admit, I’m even more confused, which could be good since it can be some important blind spot I’ve missed.
Yes, you’re right that my drawbacks apply as well to existing open source. But you’re proposing something new, something where people’s reputations aren’t involved yet [in] the way they’re involved in conventional projects.
I don’t know if you mean reputation as in skill level or reputation as in not being a bad actor.
For the first, we probably need a few round of this to see how it goes. Since trades are per project, the more skilled can put it less time. (There’s still the question of quality of the output. But I think that would have the same discussion as in the “Failure” section.)
For the second, I’m thinking the projects are small enough to make an audit not as hard.
I mean, again, this reputation problem happens for new accounts that show up on github with new projects entirely made on their own. You still have to decide to use them or not somehow. I’m not saying open source doesn’t have its drawbacks, but collaborative trades isn’t intended to solve any of those problems. Its intended to improve coordination.
And something where I have to precommit to using something that doesn’t exist yet. The competition isn’t existing open source projects. The competition is me making something myself.
But if you hire someone or even thinking of writing the software yourself, you’re still precommiting to a non-existent program (with just a spec). Basically, I didn’t understant the extra burden your are trying to highlight when comparing this to writing everything yourself.
Let me try to explain the difference anyways (but I might be going in a completely wrong direction).
Scenario: You want programs A, B, C, D (they are independent and all don’t exist).
Writing it all yourself: Takes time of writing all four of A, B, C and D. Full control over everything.
Collaborative software trade: Takes time of writing one of A, B, C or D (you don’t get to pick which one, the matcher assigns it to you). Full control over your assigned program, no/little control over the others. When you complete your assigned program, it has to be released as open source.
The result in both cases is that you now have all four programs. (In the collaborative trade, so does everyone else.)
As described, you might have to modify the three programs that you receive to better suit your needs, but the people who made them took your wishes into consideration to make editing them easier. This does means you should take others wishes into account when make your assign program.
In the case where I would write and release the source for all programs anyways, the trade is much better. Even if all other programs received this way are really bad, I can just (re)write them myself as I was going to do anyways without the trade. But most likely, I can at least salvage some useful things out of them. In the more optimistic case, what I get is much better.
I don’t follow. I don’t see the word “usage” anywhere in OP.
Sorry I meant the stuff I typed in the other reply in here:
In my case, on top of documentation (or even instead of it), I’d like to have enough instructions for rebuilding the whole thing from scratch. This means favouring simpler internals and fewer large list of cases.
For servers, we know to have script and configuration setup to restore state when the machine reboot. This would be the human version of that.
As a bonus, on top of describing what works, add a few remarks about what’d be lost with some “obvious” simplifications to the system.
I really only need the program or library to prod it to check and understand the properties it has.
What sort of stack do you use? How do you test on multiple platforms?
Most of what I’ve written is in Python, using Tkinter if graphics are needed. I did not expect the programs to be particularly cross-platform (and so no such test was done!) but I know people have tried at least on Mac. It could also be that it doesn’t work for some platforms and no-one said anything yet.
I understand that scenario from the original article. But let me try to restate my objections:
Takes time of writing all four of A, B, C and D.
I agree. But the time taken to write them may not be important for everyone.
this reputation problem happens for new accounts that show up on github with new projects entirely made on their own. You still have to decide to use them or not somehow.
True. But I look at hundreds of open source projects over the years, but start using only a few. Less than 1% yield. With trades that sort of strike rate would yield nothing.
if you hire someone or even thinking of writing the software yourself, you’re still precommiting to a non-existent program (with just a spec).
But you usually have more steering control over the process. Hmm, perhaps there’s some way to add that back into your idea? Maybe four of us start out building programs, but we meet once a week or something to chat about how it’s going. This would make it easier for us to take each other’s wishes into consideration, as you put it.
Even if all other programs received this way are really bad, I can just (re)write them myself as I was going to do anyways without the trade. But most likely, I can at least salvage some useful things out of them.
I think this is the crucial disagreement. See my strike rate with GitHub projects above. I don’t think salvaging useful things out of bad projects is either common or economic. It can take way longer to understand a bad project that does something in a bad way with 1% overlap with what you care about, than it would to just build the 1% yourself surrounded by a different 99%.
As I write this, I thought of a couple more objections that I hadn’t aired yet:
I don’t usually have a list of programs I wish existed. I usually get ideas one at a time. And then I forget the ones that I wasn’t very into, and obsess one at a time about the ones that I really care about. So I don’t know how common it is for programmers to have a list of programs A, B, C and D they wish to exist.
Oftentimes my goal when programming isn’t mainly about the utilitarian value of the final program. It’s the wish to create an “object of conversation”, a locus for collaboration with another programmer. If I found 3 other people who wanted the same programs to exist as myself, my preferred approach would be to collaborate with them on all four programs, rather than to go our separate ways and build one program in isolation. Working together just seems more fun.
These are my objections, and I care about conveying them to you just so you understand them. But I don’t mean for them to discourage you. My objections are all abstract, and if you don’t find them important that’s fine. Just keep going, and either you’ll understand them better, or you’ll discover that my theoretical objections don’t actually matter in practice, that there’s a segment of programmers who can use this even if it doesn’t include me.
I agree. But the time taken to write them may not be important for everyone.
I don’t usually have a list of programs I wish existed. I usually get ideas one at a time. And then I forget the ones that I wasn’t very into, and obsess one at a time about the ones that I really care about. So I don’t know how common it is for programmers to have a list of programs A, B, C and D they wish to exist.
I think this is indeed one of the differences.
If there is a list and the list keeps growing in size or its members in scope, the total estimated time can exceed human life expectancy. Because of how bad we are at estimate, even 10x less estimated time is cutting it too close.
Most things I want are editors and before they exist, so there also needs some time to actually use them afterward. :)
Having said that, indeed if time taken to write the programs is not important then trades don’t offer anything even in the most optimistic outcome (and so there’d be no reason to participate in that case).
True. But I look at hundreds of open source projects over the years, but start using only a few. Less than 1% yield. With trades that sort of strike rate would yield nothing.
Well, most projects I’ve looked at don’t have anything near my requirements taken into account. Do you mean that of the ones that matches your description, you only get 1% useful? Or of the ones matching keyword search had 1% yield?
But you usually have more steering control over the process. Hmm, perhaps there’s some way to add that back into your idea? Maybe four of us start out building programs, but we meet once a week or something to chat about how it’s going. This would make it easier for us to take each other’s wishes into consideration, as you put it.
I’ve thought about something along those lines. Basically, the same thing can be done with incorporating other’s requirement at any threshold since its all symmetric. So for the control gained on the other projects, you’d lose control over your own.
With it set this way, I think you’d lose flexibility on skill difference and potential asynchonicity (if we all just agree to have the projects done by some point, people can start/stop any time between now and then). Depending on how the meetings are conducted, you might also lose
I thought finding people who want the same things and have comparable abilities (for whichever measure) would be much harder. I haven’t run this yet so I don’t know.
In my particular case, I’d be happy to just take the weekly discussions as the output. Although I’d just want the final summary, not the entire thread.
It’d also be one meeting per projects since the three other people’s list aren’t the same. I don’t quite see how the logistics of that would work out yet.
I think this is the crucial disagreement. See my strike rate with GitHub projects above. I don’t think salvaging useful things out of bad projects is either common or economic. It can take way longer to understand a bad project that does something in a bad way with 1% overlap with what you care about, than it would to just build the 1% yourself surrounded by a different 99%.
You’re right. Although I think the difference in expected rate might more central to the disagreement. Yes, 1% would not make it worthwhile. (My requirements includes instructions for rebuilding it so I could tell if its worth it to dig through more easily.)
I don’t have a particular reason to think the initial rate would be higher. However, I’d like to argue that this system can maintain a high rate if it already has one, while something like Github cannot. Namely, the programmers with the lowest failure rates on Github are likely to move to much more non-open source while everyone else stays.
Here is failures can be made to net nothing (not sure how to implement that yet) and success is rewards at the system’s current rate then I think its stable (provided the time savings are a good enough reason to stay, which isn’t always the case as discussed much earlier).
Oftentimes my goal when programming isn’t mainly about the utilitarian value of the final program. It’s the wish to create an “object of conversation”, a locus for collaboration with another programmer. If I found 3 other people who wanted the same programs to exist as myself,
See the above, but its most likely that each one only wants one program in common with you. (Maybe this doesn’t affect what follows but its 3 times as much communication.)
my preferred approach would be to collaborate with them on all four programs, rather than to go our separate ways and build one program in isolation. Working together just seems more fun.
That’s partly in the “Lack of discussion” section. I don’t know how well that would work with people with different languages and libraries preference. High level discussion might still work.
Oftentimes my goal when programming isn’t mainly about the utilitarian value of the final program. It’s the wish to create an “object of conversation”, a locus for collaboration with another programmer. If I found 3 other people who wanted the same programs to exist as myself, my preferred approach would be to collaborate with them on all four programs, rather than to go our separate ways and build one program in isolation. Working together just seems more fun.
I think this is another major difference in objectives. I most definitely want the final product first. I’d much rather discuss the post-mortems with them than follow along.
(Although I’m wondering if there’s more similarity than difference here. You want to discuss and work with people. I want to be in the same state as if I had those discussions and collaborations, but reached more quickly.)
These are my objections, and I care about conveying them to you just so you understand them. But I don’t mean for them to discourage you. My objections are all abstract, and if you don’t find them important that’s fine. Just keep going, and either you’ll understand them better, or you’ll discover that my theoretical objections don’t actually matter in practice, that there’s a segment of programmers who can use this even if it doesn’t include me.
Thanks again for chiming in. This discussion is much appreciated!
hm, I think a few examples would be really useful. My first thought is that people’s requirements for the same project would be too specific for anyone to be satisfied with another’s implementation.
That and software tends to take forever to develop - like sometimes years if someone doesn’t have a specific deadline and is writing it solo in their spare time. I know the idea was to have smaller projects than that, but people are likely to underestimate by orders of magnitude
I cut the samples out because I have a pretty strong (and maybe unusual) bias in what I want. And this idea is meant to be more general.
For all programs, here’s the general property I want.
In my case, on top of documentation (or even instead of it), I’d like to have enough instructions for rebuilding the whole thing from scratch. This means favouring simpler internals and fewer large list of cases.
For servers, we know to have script and configuration setup to restore state when the machine reboot. This would be the human version of that.
As a bonus, on top of describing what works, add a few remarks about what’d be lost with some “obvious” simplifications to the system.
I really only need the program or library to prod it to check and understand the properties it has.
This means the language and library used doesn’t matter as much although being able to read the source without too much experience is definitely a plus.
As I’ve said in that post, I still need to think of projects of that scope to add myself. So what follows need more thought.
A PEG grammar for Python 3. I want to use my own parsing library but don’t mind if it uses a different library. It has to be a parsing expression grammar (PEG) using ordered choice though. The parser itself need not be written in Python, although that’d be nice. Bonus points for concision.
Definitely not for this time frame:
An extensible low level editor for interactively create low level programs (in C and assembly). I want something more visual and better than a debugger (workflow-wise, not necessarily feature-wise). Let me set/view regions of memory while the program runs or is paused.
The editor itself needs to be “simple” with relying on its extensibility (which also means making it “easy” to extend).
For a more doable project, even a much smaller (in terms of complexity, not resource use) gdb or lldb would be a good start.
That and software tends to take forever to develop - like sometimes years if someone doesn’t have a specific deadline and is writing it solo in their spare time.
Indeed and I’m unfortunately well acquainted with this problem. But this phenomenon is worst with two pieces of software, or three, or more…
In some sense, these trades are a solution to this problem although it does not face it head on.
Interesting idea. But you’re missing a couple of major drawbacks:
Software is usually a liability rather than an asset. It can increase your attack surface. It can be a time sink to maintain over time. It can not quite do what you want and bleed energy. It can be actively malicious, insidiously stealing your data or bitcoin. (I’m seeing a lot more awareness of these issues after the security vulnerabilities and Cambridge Analytica of the last few years. For example, this article can be distilled down to, “stop using software to trust people, software will never be trustworthy enough.” Software’s benefits are usually residents of Mediocristan, but its drawbacks often live in Extremistan.)
Dependencies matter. You list as an advantage that “Unless the language or library used is part of the requirements, programmers proficient in different languages can still trade.” But you’re reading that fact from exactly the wrong direction. Since anything I’m unable to get running is by definition useless, and since installing languages and libraries is non-trivial in the most general case, platform dependencies will grow to become an essential part of requirements. An obvious example: any programs I distribute are useless to someone running Windows. Another example: If I don’t want to install Java, you either don’t use Java, or you need to come up with a way to distribute your program with Java in some sandboxed fashion. (We all know how successful such attempts have been.)
With these issues in mind, I have two suggestions.
Suggestion #1: Reduce the unit of exchange. If people exchanged programs that could be built in an hour or two rather than a week or two, the programs would be more obviously right, more generally useful and easier to specify, detect duplicates, probably rely on fewer dependencies, have smaller risks for the author, etc., etc.
If the expected project size were to go down I can contribute a couple of small scripts I’ve built that I find very useful:
grep. Useful formaildirs, but since I started using it I’ve also started structuring other data sources as directories with one file per unit.(Hmm, as I look at these I notice a couple more drawbacks to your idea: 3. Many programs are demand-creating rather than demand-satisfying. People may not know they want them until they see them in action. 4. Programs often work in systems. Unix pipes. Or operating on a directory of files with one file per unit, as I do above. Or pipes operating on Yaml. Individual programs in these sets aren’t useful without the right context and environment.)
Suggestion #2: Cater to a more specific kind of person. I can imagine at least two axes to segment programmers by: time rich vs time poor and money rich vs money poor. So for example someone money rich but time poor and someone time rich but money poor would end up transacting the conventional job for money. Your current approach has benefits along both time and money axes, but the cost is the drawbacks enumerated above. For example, I’m not particularly time rich, but I know that a program I write will do just what I want, nothing I don’t want, be fairly parsimonious of dependencies, and set at least some sort of lower bound for secure practices. So if I have an idea for a program it’s better to wait and build it myself rather than try to optimize too hard for time. But maybe there’s some way to mitigate the drawbacks if you focus on just one of the quadrants?
Thanks for your thought on this.
I think you are mainly thinking of software that will be used on servers open to the internet and when I wrote this, I was mainly thinking of desktop apps used to make things (which may then be put on Internet-facing servers in production, but not the desktop app itself).
But aren’t these general problems with using open source libraries in your projects (and not something specific to trades)?
Depending on how bad it is, I’d argue that you didn’t actually get the software you wanted if it ends up being so much trouble. (And consequently shouldn’t be used despite another user having made it, which is unfortunate but avoids the downsides.)
Maybe I just happen to make stuff that’s more cross platform by default.
See the “usage” pattern I described. In my case, not being able to run it would still lose a lot of value, isn’t useless.
Suggestion #1: I’m happy to try this version if there’s enough people.
Though I don’t think I have anything I could safely say can be made in 1-2 hours from scratch. Any random hiccup can take up the entire time. It also makes thinking about and writing out the specs a bit less worthwhile.
But I don’t know. “A weekend” wasn’t that thought out of a time length either. So I’d give this one a go if more people prefer it.
I hadn’t thought of just releasing existing source. But that works too! Really any way works, even finding an existing project (if licenced right).
You still have to add programs that you want. And the way I described it, it could be that someone else is assigned to make
searchandaccumulate(which you already have) while you’re assigned something else from your list.I guess people can browse the existing list, although this doensn’t help see it in action. I was thinking more of programs that do not yet exist so you couldn’t see them in action anyways.
Suggestion #2 This is an interesting suggestion but I didn’t entirely follow your discussion.
How would focusing on only one quadrant (potentially) help with the drawbacks listed? Do you mean all the time poor, money right would tend to want the same kind of things?
Or do you mean some of the quadrants wouldn’t find the drawbacks as much?
(I’m in no way in disagreement, just didn’t follow the reasoning entirely.)
Yes, you’re right that my drawbacks apply as well to existing open source. But you’re proposing something new, something where people’s reputations aren’t involved yet the way they’re involved in conventional projects. And something where I have to precommit to using something that doesn’t exist yet. The competition isn’t existing open source projects. The competition is me making something myself.
(I’m trying to attack these drawbacks for open source as well.)
I don’t follow. I don’t see the word “usage” anywhere in OP.
What sort of stack do you use? How do you test on multiple platforms?
Thanks again for your thoughts. I have to admit, I’m even more confused, which could be good since it can be some important blind spot I’ve missed.
I don’t know if you mean reputation as in skill level or reputation as in not being a bad actor.
For the first, we probably need a few round of this to see how it goes. Since trades are per project, the more skilled can put it less time. (There’s still the question of quality of the output. But I think that would have the same discussion as in the “Failure” section.)
For the second, I’m thinking the projects are small enough to make an audit not as hard.
I mean, again, this reputation problem happens for new accounts that show up on github with new projects entirely made on their own. You still have to decide to use them or not somehow. I’m not saying open source doesn’t have its drawbacks, but collaborative trades isn’t intended to solve any of those problems. Its intended to improve coordination.
But if you hire someone or even thinking of writing the software yourself, you’re still precommiting to a non-existent program (with just a spec). Basically, I didn’t understant the extra burden your are trying to highlight when comparing this to writing everything yourself.
Let me try to explain the difference anyways (but I might be going in a completely wrong direction).
Scenario: You want programs A, B, C, D (they are independent and all don’t exist).
The result in both cases is that you now have all four programs. (In the collaborative trade, so does everyone else.)
As described, you might have to modify the three programs that you receive to better suit your needs, but the people who made them took your wishes into consideration to make editing them easier. This does means you should take others wishes into account when make your assign program.
In the case where I would write and release the source for all programs anyways, the trade is much better. Even if all other programs received this way are really bad, I can just (re)write them myself as I was going to do anyways without the trade. But most likely, I can at least salvage some useful things out of them. In the more optimistic case, what I get is much better.
Sorry I meant the stuff I typed in the other reply in here:
Most of what I’ve written is in Python, using Tkinter if graphics are needed. I did not expect the programs to be particularly cross-platform (and so no such test was done!) but I know people have tried at least on Mac. It could also be that it doesn’t work for some platforms and no-one said anything yet.
I understand that scenario from the original article. But let me try to restate my objections:
I agree. But the time taken to write them may not be important for everyone.
True. But I look at hundreds of open source projects over the years, but start using only a few. Less than 1% yield. With trades that sort of strike rate would yield nothing.
But you usually have more steering control over the process. Hmm, perhaps there’s some way to add that back into your idea? Maybe four of us start out building programs, but we meet once a week or something to chat about how it’s going. This would make it easier for us to take each other’s wishes into consideration, as you put it.
I think this is the crucial disagreement. See my strike rate with GitHub projects above. I don’t think salvaging useful things out of bad projects is either common or economic. It can take way longer to understand a bad project that does something in a bad way with 1% overlap with what you care about, than it would to just build the 1% yourself surrounded by a different 99%.
As I write this, I thought of a couple more objections that I hadn’t aired yet:
I don’t usually have a list of programs I wish existed. I usually get ideas one at a time. And then I forget the ones that I wasn’t very into, and obsess one at a time about the ones that I really care about. So I don’t know how common it is for programmers to have a list of programs A, B, C and D they wish to exist.
Oftentimes my goal when programming isn’t mainly about the utilitarian value of the final program. It’s the wish to create an “object of conversation”, a locus for collaboration with another programmer. If I found 3 other people who wanted the same programs to exist as myself, my preferred approach would be to collaborate with them on all four programs, rather than to go our separate ways and build one program in isolation. Working together just seems more fun.
These are my objections, and I care about conveying them to you just so you understand them. But I don’t mean for them to discourage you. My objections are all abstract, and if you don’t find them important that’s fine. Just keep going, and either you’ll understand them better, or you’ll discover that my theoretical objections don’t actually matter in practice, that there’s a segment of programmers who can use this even if it doesn’t include me.
Thanks again. Now I understand.
These two probably go together.
I think this is indeed one of the differences.
If there is a list and the list keeps growing in size or its members in scope, the total estimated time can exceed human life expectancy. Because of how bad we are at estimate, even 10x less estimated time is cutting it too close.
Most things I want are editors and before they exist, so there also needs some time to actually use them afterward. :)
Having said that, indeed if time taken to write the programs is not important then trades don’t offer anything even in the most optimistic outcome (and so there’d be no reason to participate in that case).
Well, most projects I’ve looked at don’t have anything near my requirements taken into account. Do you mean that of the ones that matches your description, you only get 1% useful? Or of the ones matching keyword search had 1% yield?
I’ve thought about something along those lines. Basically, the same thing can be done with incorporating other’s requirement at any threshold since its all symmetric. So for the control gained on the other projects, you’d lose control over your own.
With it set this way, I think you’d lose flexibility on skill difference and potential asynchonicity (if we all just agree to have the projects done by some point, people can start/stop any time between now and then). Depending on how the meetings are conducted, you might also lose
I thought finding people who want the same things and have comparable abilities (for whichever measure) would be much harder. I haven’t run this yet so I don’t know.
In my particular case, I’d be happy to just take the weekly discussions as the output. Although I’d just want the final summary, not the entire thread.
It’d also be one meeting per projects since the three other people’s list aren’t the same. I don’t quite see how the logistics of that would work out yet.
You’re right. Although I think the difference in expected rate might more central to the disagreement. Yes, 1% would not make it worthwhile. (My requirements includes instructions for rebuilding it so I could tell if its worth it to dig through more easily.)
I don’t have a particular reason to think the initial rate would be higher. However, I’d like to argue that this system can maintain a high rate if it already has one, while something like Github cannot. Namely, the programmers with the lowest failure rates on Github are likely to move to much more non-open source while everyone else stays.
Here is failures can be made to net nothing (not sure how to implement that yet) and success is rewards at the system’s current rate then I think its stable (provided the time savings are a good enough reason to stay, which isn’t always the case as discussed much earlier).
See the above, but its most likely that each one only wants one program in common with you. (Maybe this doesn’t affect what follows but its 3 times as much communication.)
That’s partly in the “Lack of discussion” section. I don’t know how well that would work with people with different languages and libraries preference. High level discussion might still work.
I think this is another major difference in objectives. I most definitely want the final product first. I’d much rather discuss the post-mortems with them than follow along.
(Although I’m wondering if there’s more similarity than difference here. You want to discuss and work with people. I want to be in the same state as if I had those discussions and collaborations, but reached more quickly.)
Thanks again for chiming in. This discussion is much appreciated!
hm, I think a few examples would be really useful. My first thought is that people’s requirements for the same project would be too specific for anyone to be satisfied with another’s implementation.
That and software tends to take forever to develop - like sometimes years if someone doesn’t have a specific deadline and is writing it solo in their spare time. I know the idea was to have smaller projects than that, but people are likely to underestimate by orders of magnitude
I cut the samples out because I have a pretty strong (and maybe unusual) bias in what I want. And this idea is meant to be more general.
For all programs, here’s the general property I want.
This means the language and library used doesn’t matter as much although being able to read the source without too much experience is definitely a plus.
As I’ve said in that post, I still need to think of projects of that scope to add myself. So what follows need more thought.
Definitely not for this time frame:
The editor itself needs to be “simple” with relying on its extensibility (which also means making it “easy” to extend).
For a more doable project, even a much smaller (in terms of complexity, not resource use) gdb or lldb would be a good start.
Indeed and I’m unfortunately well acquainted with this problem. But this phenomenon is worst with two pieces of software, or three, or more…
In some sense, these trades are a solution to this problem although it does not face it head on.