How about open-source?

[exp]

I'd guess you could just have the server-side ban anyone doing more than X ops/hour from one IP, doesn't sound like rocket science to me :-) Also, the access isn't anonymous anyway so I don't see the point - sure, they might at best cause some annoyance once but then they'd be gone.

yeah the api could be made more robust on the server side, however that would require quite some work and i don't have the time to do it.

And as deterrence method, even with current client authentication scheme I could spam requests easily enough with unauthenticated code, how to do it as left as exercise to the reader.

i don't think that we'll have problems with ppl who actively try to break anidb, at least not many of them.
but if the API specs were open and everyone could write his own little client at least 2/3 of them would be broken in some way (from the API point).

..., but I don't personally care for fork in the project anyway so it's academic point only.

I am glad to hear that :o)

That's the major problem, most people in world (from my experience with few projects, both CSS and OSS) are not _seriously_ interested, they usually care only about some changes to the existing status quo within projects and the more they need to work to get changes done, the less likely they're to do anything useful.

so?

BYe!
EXP

[bbaab]

(...)

At least with earlier versions of SQLite, the default mode used fsync every transaction or so on UNIX and something even more disgusting on Windows, which made it abysmally slow. I'm not aware of the current state of the project, but check pager.c / sqlitepager_set_safety_level (those high default safety levels are only meaningful for industrial databases, if you're doing something "for fun" style, you probably care more about speed).

(...)

More like sqlitepager_set_cachesize() with a negative cache size, if I read pager.c correctly (see http://www.sqlite.org/cvstrac/getfile/s ... r.c?v=1.92 - introduced in v1.42 of this file). Damn in-band signaling.

[fingon]

Actually, following function call sequences are identical:

sqlitepager_set_safety_level(p, 1);
sqlitepager_set_cachesize(p, 123);


versus

sqlitepager_set_cachesize(p, -123);

(Benefit from using set_safety_level is that you can use whatever cachesize it was using in the first place ;->)

-F

[Guest]

As a maintainer of an open source project, I must respond to this thread. I have several years of experience with open source projects.

1) working with multiple ppl on one program is always a problem. ATM there's exactly one person who works on each softeare part.

This is what version control systems like CVS are for. When used properly, multiple people can work on the same part of the software with little hassle.

getting more ppl on any of those projects will be a hassle. if those ppl are not dedicated enough we lose more time to get them up to speed than we gain later.

I don't see the logic here. Making AniDB open source doesn't mean you must allow everybody to make the software. You can do it this way: keep everything as it is. The same people who worked on certain parts of the software, keep doing that. The only change is that people are allowed to submit patches. Notice the "allowed". It doesn't mean you have to accept patches.

2) we want to gather as many users on anidb as possible, the db lives only due to users who add data. creating anidb offsprings would therefore be a mayor problem for us. however that's exactly what would happen within a short period of time should we make all the code public.

Ah, the usual fear for forking. According to my experience, the biggest reason why anybody would want to fork a project, is because the project leadership sucks. People don't fork stuff for fun you know?
In other words: as the project leader you should encourage cooporation as much as possible. Make sure people don't conflict with each other or anything. If someone wants to fork, talk to him and see if you two can come to a compromise to prevent it from happening. Usually you can, unless his goal is too different from yours.
However, if his goal is that different, then that also means his userbase will be different. The impact on your userbase will not be big.

Another thing to keep in mind is how long those forks can survive. Without enough popularity, and without proper maintenaince, the fork will die a quiet death. It's not like, when someone forks AniDB, your community will suddenly split into two. If the fork sucks, nobody will use it.

In short: the creation of offsprings is not what will exactly happen. It mostly depends on you, and how you will maintain the project. My project is pretty popular. Since it began 9 months ago, there have been no forks at all.