Home › Forums › General

Too busy?

Tue, 2006-10-31 13:07 — Plinker007

The update says the creator or whoever has been too busy. I can't fathom someone being to busy for this. If I had even half the knowledge to get this project off the ground, you better believe I'd be all over it. I'm sure we all have had to think of the money that is involved here. I would have paid for blue security, and I'm willing to pay (donate or whatever) for the Okopipi when it gets off the ground. This is a very lucrative project here. I'm sick of the spammers and am ready to fight. There's probably another million people out there ready to donate to the cause just to stop these spammers.

‹ New Project Leader 100% Deaded and no surprise ›
Fri, 2006-11-03 08:57 — Gordon C Harrison

Too Busy? Is money needed?

I am concerned too that such an important project for the entire internet community seems to be struggling to either get or organise the resources needed to move this project to a conclusion. Okopipi has the potential to kill spam for good for everyone - the whole world will rush to you with money to buy your product when it's released.

Would it help for all the Okopipi supporters to make a donation to fund development at this stage? Would that help gain the resources needed? Once the software is up and running and earning mountains of money the supporters who donated can be repaid.

Who is going to market this product when it's ready? Has a company been formed to market and manage the sales? Do we have web designers available to set up an e-commerce site for Okpopipi? Could an existing software company be persuaded to commit resources for a share of the future profits?

Getting coders is only part of the problem. Okopipi needs someone with a good business head to lead and manage the development of the project, and that person or someone else to subsequently manage the company that will need to be formed to sell, maintain and further develop the product post implementation.

I for one am willing to support Okopipi financially.

Gordon

Sat, 2006-11-04 08:38 — Poltergeist

Thank you for your support.

Thank you for your support.

Would it help for all the Okopipi supporters to make a donation to fund development at this stage?

Thanks, but in my case this would not help, money cannot change the fact that I'm tied up until (most likely) February.

Of course it might be different for other coders. I'm surprised that there are no other coders working on an alternate frog. Maybe one reason for this is that, when you analyse the task in careful detail, there are some seriously difficult problems involved.

However, if we arrange a money fund, this might attract people who don't really have solutions to these difficult problems, but want the money. This might complicate the project, with partial projects that aren't really going anywhere.

A more important risk is that mafioso spammers might follow the money. More on this below.

Okopipi has the potential to kill spam for good for everyone -

I think this is optimistic because it will be an arms race. Spammers will refine ways to outsmart Okopipi, and we will refine ways to outsmart them.

I think Okopipi will make a great difference, it looks very promising, but still it will be quite a struggle.

- the whole world will rush to you with money to buy your product when it's released.

I do think Okopipi may become effective enough to attract this kind of attention and money, should we set things up this way. However...

Has a company been formed to market and manage the sales?

...I have serious doubts that a company that distributes Okopipi and earns profits would survive for long. Such a company would become a very vulnerable point to attack. Note how Blue Security was struck down.

Unless I'm mistaken, spam gives fantastic profits to, among others, organised crime, mafia. If we threaten their profit, and have a company that is making profit, the criminals can not only DDOS that company like they DDOSed Blue Security. If they find that DDOS attacks don't stop us they can follow our company money to track down key people, and then use threats, extortion, kidnappings, and so on.

A very loosely coupled network, with all the key people anonymous, is much safer. Even better if we can avoid having any key people at all, so there are no vulnerable points they can attack.

I think the reason they're not attacking us so far, is that so far we are no threat to them, and we have not yet shown any real evidence that we will ever be.

In conclusion I think that, even though theoretically Okopipi has tremendous economic potential, in practice, reaping this profit would most likely be very risky, at least for key people.

And because of these risks, I think it's better to have lots of patience, and let Okopipi develop in ways that may be slower, but are safer for the people involved.

Mon, 2006-11-13 05:55 — secondwheel

Difficult compromise

I totally agree that putting a real company and real people in front of Okopipi would make it/them quite vulnerable... but I also would point out that BlueSecurity failed primarily because their software design had a few huge weak points:
* it allowed their customers to be attacked directly
* it required large (and expensive) centralized resources that needed to be paid for and were also easily attacked

Founding a non-profit to centralize Okopipi's development wouldn't risk either of those things (since even if their site were shut down periodically, the network would continue to function), but it would expose the real people in charge.

I think we're better off working scattered... but this is *very* difficult without someone who knows what they're doing holding the tiller. People squabble over minor details and disappear in a huff, people misread comments and get offended, there's no one to make "final" decisions and have people move on.

I'd suggest having the latest design doc front and center on the site, written by just a few people, and solicit comments and discussion from the rest of us. Go through a couple phases of rewrites, then break everything up into many separate proof-of-concept mini-projects.

Each proof-of-concept would get its own page on the site or wiki (linked from the home page -- this is what we want incoming developers to see!), and anyone can contribute code in any language. Sticky issues (like how to write a Thunderbird/Outlook/etc. plugin that reports spam to a local port) should be at the top to get knocked off quickly.

Once we have decent coverage of these areas, then get a main development team going based on who actually found time to contribute to the PoCs, not just who's the most enthusiastic.

Thoughts? Is there somewhere else I should be posting this advice? ...

Mon, 2006-11-20 18:05 — Poltergeist

I think what we need is code

Sorry about the very long time it's taken me to respond.

secondwheel wrote:
but this is *very* difficult without someone who knows what they're doing holding the tiller.
...
I'd suggest having the latest design doc front and center on the site,
...

This sounds very reasonable, and yet I'm not convinced. I get the impression that this project resists all attempts to develop it through design docs and people holding the tiller. Several attempts have already been made.

Of course I could be wrong. Maybe it just hasn't been attempted the right way yet. Maybe.

But I'm not worried. I think all that's missing here is code. I think things will start moving once I release my prototype (or if other people should release another prototype). With a prototype that we can discuss, several problems that are now nebulous will become far more specific. This makes them much easier to describe and discuss. With this, working on the solutions will become much easier.

Even if it should turn out that my solutions don't work in large-scale tests (which really would surprise me quite a lot), I'm still pretty confident that the release of a prototype that we can discuss and work on will be a spark that will get development going.

secondwheel wrote:
Is there somewhere else I should be posting this advice? ...

It seems some people read only our Google groups and don't come here. It may be a good idea to post your thoughts there too.

Tue, 2006-12-19 14:50 — secondwheel

My reasoning

The reason I suggested getting the design (even what we have) out front is based on what I see on the site now -- I *do* know how to code, and have a lot of design experience, and sometimes I have scraps of spare time that I could use for some proof of concept code, or offering design feedback.

But with the current setup (no discussion of design, no "proof of concepts to do/in progress", just a couple of people maybe working on secret, solo prototypes) I cannot contribute anything. I see mentions of Okopipi pop up on Slashdot periodically, and elsewhere, but any developers who stop by will see exactly what I see, and go away without having seen anywhere they could help.

The release of a prototype would certainly help things, because that's a tangible thing -- people can read the code and submit patches, suggestions, etc.. But it's strange to just let useful resources just disappear in the months before you have anything to put up. Do you seriously have *no* technical issues that are TBD? All you have to do is throw it out there, make sure it's visible on the home page, and check back when you get around to actually working on that section to see if you collected some useful comments.

This is a particularly good time to do that, if your actual development is on hold until February....

Wed, 2006-12-27 18:23 — Poltergeist

Reasonable reasoning

I agree with almost everything you say.

The problem is, I did try to discuss my solutions, and it simply didn't work. I really tried. I described my solutions, assuming that this would lead to collaborative developmennt, which would start with constructive discussion, with people contributing ideas and improvements, together constructively looking for solutions to as-yet unsolved problems, and so on. And after this collaborative discussion we'd proceed to collaborative coding. Something like that.

Instead I got a barrage of persistent fault-finding from two "leaders" who felt that my solutions wouldn't work and/or were too experimental. I had the feeling that I just couldn't get my ideas across. I spent a huge number of hours hitting a brick wall over and over again. All my hours of effort lead to no meaningful result at all.

Probably I'm not good at describing this kind of stuff. Or maybe the solutions I've come up with are too unusual and difficult to describe.

In any case I don't want to once again waste time struggling with fruitless attempts to get my ideas across. At the moment I don't /have/ that time. Showing everyone a working prototype will be much quicker, much easier, and definitely much more convincing. The prototype will convince by /showing/ that the solutions work. This is the path I want to use, because it will work much better than pounding that brick wall all over again.

If you really want a description, then please read my posts in our Google Groups okopipi-dev and okopipi-discuss. Start with my posts /Scalable Trust/ and /Scalable Trust 2/. But I posted descriptions in several other threads too. Practically everything I posted at that time was descriptions of my solutions. It's available there for anyone who wants to read a description. I didn't get very far into details, since I spent most of the time hitting that wall, but I think all the basic stuff is there.