Raising money to 'Open-Source' kaya.gs

[Mike Novack]

Question --- Why are you assuming that becoming "open source" would address the problem of lack of development of what users want?

With volunteer open source projects, what gets worked on depends on what the volunteer programmers decide to work on, what interests them.

Don't get me wrong, I am all in favor of open source projects but this is one aspect of the difference between "for profit" software and "open source" volunteer software where the "for profit" might have an edge. If somebody is paying me to develop software, they get to decide what I work on (*) which might not be what I'd most like to work on because more interesting. But if I am volunteering, no such leverage.

* -- well in my case the leverage would be minimal as I am retired and would only agree to come back into the cypher mines if I thought the project interesting. I don't need the money.

[Kaya.gs]

Question --- Why are you assuming that becoming "open source" would address the problem of lack of development of what users want?

With volunteer open source projects, what gets worked on depends on what the volunteer programmers decide to work on, what interests them.

Don't get me wrong, I am all in favor of open source projects but this is one aspect of the difference between "for profit" software and "open source" volunteer software where the "for profit" might have an edge. If somebody is paying me to develop software, they get to decide what I work on (*) which might not be what I'd most like to work on because more interesting. But if I am volunteering, no such leverage.

* -- well in my case the leverage would be minimal as I am retired and would only agree to come back into the cypher mines if I thought the project interesting. I don't need the money.

Its an intersection. On OpenKaya, pretty much all collaborators did what they wanted, from their very own ideas, filtered by what is possible or desirable.

[Bantari]

Cool!

So, if Kaya is open to open-source itself, and even to control itself, there remain two questions:
1. For how much? and
2. Are there competent people out there willing to seriously work on it? For free?

There are other, less urgent questions as well, but the above two are really important before anybody starts raising funds and dreaming pretty.

@Mike:
I agree with you that open sourcing does not guarantee that the features users want will actually be developed. Its a very good point. In the long run, it might require direction and a person doing the directing. Which brings two issues: (a) how much ownership will this person have, and (b) how open will this person be to community needs. Especially (b) can be an problem.

@Kaya:
Your point about intersection is a good one too, but it assumes a plentitude of contributors with enough different ideas so that most desirable features get implemented. This is a very big assumption. In case of Kaya, I really don't see that happening, but I might be wrong. It all depends on the answer to my question #2 above.

[Mike Novack]

Cool!
In the long run, it might require direction and a person doing the directing. Which brings two issues: (a) how much ownership will this person have, and (b) how open will this person be to community needs. Especially (b) can be an problem.

Close but no cigar. You almost understand the problem but don't quite grasp it.

With volunteers, they have to want to work on some particular aspect of the project. Look, some software is fun and other parts, however important ot necessary or desired by users just plain boring or tedious. And there are some of us who were very experienced in the real world and will simply refuse to take on a user requested project (me, for example) unless the users are willing to commit to their part of it (and yes, there jobs for users from a detailed "requirements" statement* all the way through testing). I've been on "help" for a number of open software apps and typically the users say they want something but very rarely will commit for their part of the job.

The point I am making is that in the "real world" the boss (management) can give orders "you do that" and "that" gets worked on because that's what your pay check depends upon. But you simply can't order volunteers around like that.


* If there is no such detailed definition of what a program is supposed to do under any an all circumstances then whatever it does is "correct" provided the program doesn't hang or loop. Understand? As a software designer I can't read the user's mind for what they expect. In the real world that detailed design phase might be 20% of the total time commitment for the project.

This is essentially a misunderstanding of roles. As an experienced analyst, I know how to sit down with users and from the rough description of what they say they want keep asking questions like "but what about in this case" until the functionality is fully defined. Keep in mind that as a rule of thumb 80% of the code will be dealing with all these rare situations that the users didn't envision but which must be handled properly. Imagine how frustrating for one of us to (first) create what the users said they wanted and then having the users keep complaining "wrong!" over and over till all of those loose ends get tied up.

[Bantari]

Cool!
In the long run, it might require direction and a person doing the directing. Which brings two issues: (a) how much ownership will this person have, and (b) how open will this person be to community needs. Especially (b) can be an problem.

Close but no cigar. You almost understand the problem but don't quite grasp it.

With volunteers, they have to want to work on some particular aspect of the project. Look, some software is fun and other parts, however important ot necessary or desired by users just plain boring or tedious. And there are some of us who were very experienced in the real world and will simply refuse to take on a user requested project (me, for example) unless the users are willing to commit to their part of it (and yes, there jobs for users from a detailed "requirements" statement* all the way through testing). I've been on "help" for a number of open software apps and typically the users say they want something but very rarely will commit for their part of the job.

The point I am making is that in the "real world" the boss (management) can give orders "you do that" and "that" gets worked on because that's what your pay check depends upon. But you simply can't order volunteers around like that.


* If there is no such detailed definition of what a program is supposed to do under any an all circumstances then whatever it does is "correct" provided the program doesn't hang or loop. Understand? As a software designer I can't read the user's mind for what they expect. In the real world that detailed design phase might be 20% of the total time commitment for the project.

This is essentially a misunderstanding of roles. As an experienced analyst, I know how to sit down with users and from the rough description of what they say they want keep asking questions like "but what about in this case" until the functionality is fully defined. Keep in mind that as a rule of thumb 80% of the code will be dealing with all these rare situations that the users didn't envision but which must be handled properly. Imagine how frustrating for one of us to (first) create what the users said they wanted and then having the users keep complaining "wrong!" over and over till all of those loose ends get tied up.

So you are basically saying that (and correct me if I am wrong, I am just speaking from my limited experience in open-source projects),

1) no matter how much the director directs, you can't just order volunteers around - they will still only work on what they want to work on, regardless of what is actually needed? and if you try to force them to work on other stuff, they just walk... (I know, I walked myself once or twice for such reasons, although I really did never think of it quite like that from the leader's perspective)

2) no matter how much the director listens to the public, it is not at all given that the public actually has a precise understanding of what it wants? so they scream for something just to keep screaming they want it differently once you finally implement it, making the whole process frustrating... (I had a LOT of this happen to me on each project I worked on, even though the shareholder base was very limited, so I can imagine how bad it must be when wide public is involved.)

[duckweed]

So you are basically saying that (and correct me if I am wrong, I am just speaking from my limited experience in open-source projects),

1) no matter how much the director directs, you can't just order volunteers around - they will still only work on what they want to work on, regardless of what is actually needed? and if you try to force them to work on other stuff, they just walk... (I know, I walked myself once or twice for such reasons, although I really did never think of it quite like that from the leader's perspective)

2) no matter how much the director listens to the public, it is not at all given that the public actually has a precise understanding of what it wants? so they scream for something just to keep screaming they want it differently once you finally implement it, making the whole process frustrating... (I had a LOT of this happen to me on each project I worked on, even though the shareholder base was very limited, so I can imagine how bad it must be when wide public is involved.)

Frankly the only way to direct a opensource project is by writing code.

People can say they prefer other ways of doing the project but its all hot air compared to functional code.

[dfunkt]

Nova.gs rocks!

[karaklis]

+1.

The tournament function is a feature that attracts players.
So there are games even though there are much less players than at Kaya.gs. Maybe implementing such a function would help kaya to get more ppl playing there.