Reply to post #22 (show post):
Thanks, BookStooge.

Yeah, that would kill aNobii for me, too. I have bazillions of Kindle books.

Well, if kindle books are out at aNobii, then so am I. Might just cancel that account.

JL makes a good point about the numbers of people involved. I have no idea how much it would cost to buy BL or to build and run a new site from scratch, plus cover the annual operating expenses, but I expect it’s more than a couple dozen people could afford unless some of those people have a LOT of spare money.

I would be willing to contribute some money, but I’m not rich so I don’t know if I would make much of a dent in the cost. I would also want to see a solid plan in place. As others have mentioned, it isn’t just about money. It takes a lot of time to maintain and build a site like this, and I think that plays at least some role in sites like this fizzling out. People start off with great ideas and ambitions, but they either don’t have the necessary skill set and/or they weren’t prepared to spend every waking moment of their life on the project.

Finding people with good organizational skills and good customer-facing skills shouldn’t be too hard, but the technical skills would be more difficult. It would also be more difficult to screen people for the technical jobs to determine whether they really have the required skill set. I’ve seen people hired for roles they clearly had no skill or aptitude for, by managers who didn’t have the knowledge themselves to properly screen those people. Since this wouldn’t exactly be a stable venture, the type of applicants we’d get might be more desperate than skilled and experienced.

In particular, if we were to consider buying BL, we’d need to know much more about their platform so we could figure out how to get the necessary expertise:

1. What kind of database do they use? There are surely several of us with extensive experience designing and using a standard, relational, SQL-based database. If that’s what they use, this would be the easiest technical role to fill, possibly even with volunteers. On the other hand, I believe NoSQL databases have become more common in situations where large amounts of data need to be accessed quickly, and/or where the database needs to be created quickly. It’s possible that’s what BL uses. Given some of the bugs we’ve seen in the past, I’ve always suspected BL either has the world’s worst-designed relational database or else they have some sort of database completely outside my experience like NoSQL.

2. What kind of servers do they have? Windows? Unix? How many, and where are they hosted? How do they secure them? Aside from occasionally rebooting servers at work, or accessing them to check the status of various jobs, I know nothing about server administration so I’m not even sure what questions one would need to ask.

3. What programming language and environment do they use? Ideally, you’d want a programmer who knows the programming language, has a lot of experience with web-based applications, has a good work ethic, and is truly good at writing clean, efficient code. It would probably be difficult to find somebody with all four of those skills who is also willing to take a risky, unstable job. At work I've seen truly horrible coding by “professional” programmers with years of experience who should have taken some other path in life, and they do at least as much harm as good. On the other hand, while a good programmer can pick up a new language pretty easily since the basic concepts are the same, they would have a longer learning curve and that would add delays during a time when quick progress is needed to get things off the ground and profitable.

Even if the programmer knows the programming language, there might be a human language barrier. If the comments and variable names within the code are based on the Polish language, it will be harder to read the code and understand what it currently does. And of course there’s no telling what kind of code we’d get. Given some of the bugs we’ve seen, and their apparent difficulties with resolving them, I suspect BL does not have clean, modular code that can be easily understood and modified.

Those were just a few random thoughts I had while reading the thread. I think it’s good to investigate and consider all our options, but I just wanted to bring up some of the potential pitfalls so they can hopefully be avoided. It would probably be worth talking to admins at some of the lesser-known sites, even if they're lacking features that are important to us, to gauge how invested their staff is and see if they'd be willing to make changes and improvements if we brought them in an influx of new and active members. If such a site exists, that would surely be the easier and faster route, but finding a site like that may be just as difficult as the other options.

Reply to post #26 (show post):
YouKneeK -- Good points, all.

Humorous sidebar to one of them: True story. Thirty years ago, the mfg company I worked for suffered a horrendous fire that destroyed -- literally melted into a blob -- the mainframe computer. Back-ups and documentation were salvaged, but certain details of modification were lost, esp to the inventory cost system, which was my dept. After the programmers had made numerous changes w/o achieving the correct results, they got ticked off because I had to keep telling them, "Sorry, that's not the right change either. It has to be two different dates, one before the inventory was taken and one after." Finally, in angry frustration after a week of failures, the head of IT plopped a print-out of the whole inventory program on my desk, one of those massive binders of 11 x 17 green bar paper about six inches thick, and told me, "Here, you read it. It's in some programming language none of us can make heads or tails out of." They knew I didn't have any clue about programming languages or anything even remotely close. Terrified, I opened the binder, skimmed down the lines of what must have been total gibberish to them, and then pointed to the exact places they needed to make their date modifications. It took me about 20 seconds.

It wasn't a programming language; it was Italian.

Reply to post #27 (show post):
LOL, that is funny, and it’s so easy to picture that happening. Did they consult with you for further translations? :)

Reply to post #28 (show post):
;-) No, they didn't consult me, or even thank me, but they did get the problem fixed.

And for whatever it's worth, aNobii.com is Italian. I can read quite a bit of what they have in their threads, but not all of it.

Ok, I've been thinking about all of this a lot and most of what Themis and YouKneeK have mentioned above has flitted in and out of my head. I'm going to write a novel here, sorry. I'll try to keep it clear and concise to the points they've made, then include my own at the end.

First, I'm NOT a programmer or DB admin or a DB designer (which are usually two different positions) but all my career I've worked closely with both so this is just what I've learned/absorbed over the years.

To Themis' points:
1. I LOVE the blogging format which is something I thought I'd never say - but to be clear, I love it because it's setup the way it is on BL, with the consolidated dash you can comment from. I know of no other interface that currently offers this, although I've never heard of Bloglovin'.

The BL dashboard page is built from a combination of frames (think browser windows within browser windows) and dynamic HTML that queries a database of posts. Dynamic HTML is a web page that is built only when it is queried, or requested. So, when you call up Booklikes.com, the HTML server queries the post database, finds all posts by those your following and lays them out in date/time order. The widgets you see on the side (currently reading, reading challenge, etc.) are iframes of additional embedded web pages (and each of those also query a database for their information.

NOTE: From what I can ascertain, the book database is a separate database from the posts database, so there are actually two databases involved (at least). This allows us to post non-book related stuff as well as protects our reviews from being deleted by someone when a book is deleted, etc. It's more work, but I can see the advantages of it.

I mention all of this because a new site would require an advanced HTML/Javascript coder that could re-create the complexity of what we currently have and love. They might have gone half-assed on their database designer (see below though) but I think whomever designed their web interface knew what they were doing; not that there isn't room for improvement, but what we have here is solid and sophisticated.

2. The Book Database. Short answer to Themis' question: No we don't need to pay a feed, we could build it organically.

The longer answer: Designing the database right from the beginning is the make or break crucial thing. For all practical purposes, one a relational database is built, you can't really change it. That's why GR has never added half-stars, or why they've yet to fix their disambiguation issues, etc. It's a giant pain in the ass and very very expensive to change a relational database once it's built (unless the new nonSQL databases have advanced far enough to get past this but I've never seen evidence of it).

So before you even start to think about how to build up the database you have to spent a LOT of time thinking about how to build it. Think about the obvious book information data and then add the following:
A. Disambiguation of authors
B. How to account for reused ISBNs
C. Pseudonyms (multiples)
D. Dates: do you allow partial dates (1996 vs 1996-01 vs 1996-01-01)? This is important because it affects the ability to sort all sorts of different stuff. Relative dates can't be sorted unless you ONLY use relative dates. Sorting requires separate fields for day, month and year. (This is why GR can sort by date but you have to make up days and months if you don't know them - this is also why you can't sort by date here on BL, because it allows relative dates.)
E. Multiple covers for the same ISBN - the database has to be designed to allow multiple images per edition record and a way to choose which one to display.
F. Less important: Defined book formats. If you want to sort search results by paperback or hardcover or ebook, these have to be pre-defined.

I'm certain I'm forgetting stuff too, but that gives you an idea. Once we had the database built we wanted, we could easily rely on our own private book data to populate the database. Only 2 caveats:
1. New users: This ties into whether or not we want to aggressively grow a user base or try to sustain a small, curated user base. New users "off the street" are going to expect an existing robust database. That's why Leafmarks eventually went with an Ingram feed, IIRC.

2. New book imports - What happens when we want to add new books; new releases, new finds, new scheduled releases? Are we willing to enter each one of those in by hand every time, or do we want some way of sucking that information in from another source. If the former, that's asking members to have a lot of patience and devotion (which I'm ok with) and book hauls are going to be onerous. ;) If the latter, that's a book import feed we'd have to pay for, either monetarily or with our souls (*cough*Amazon*cough*). A third option might be to find someone who'd be willing to write an app/browser plug in that would scrape book sites for title/cover/ISBN/author etc. Although that would require our programmer to write API's.

Personally, I'd much rather have a curated database - in fact, in a fantasy world, I'd like to have three: Books, comics and fan/online fiction/magazines. Because I'm a purist and I don't think anything modern (post 1970) without an ISBN should be allowed in the book database, but also because I'm not willing to blow off friends who think otherwise. If you ever went the paid membership route, you could charge a small premium to members who wanted access to the additional databases. But I digress... In summary, I hate all the crap that comes in on imports like outdated manuals, minutes of meetings of obscure committees and organisations, etc. and if nobody wants them, why waste the storage space?

To answer Themis' fundamental question - I fall somewhere in between. I want this community, and I want to be open to new members. BUT if I owned BL my goal would never be to get big, or compete with GR on a membership/numbers level. I'd be wanting to attract people who actually love books and reading and are looking for quality over quantity; positive, constructive discussions over free books (although free never sucks), and the best book data they can find and who are willing to chip in to build up the community. Oh, and a lot of patience, because there'd be a lot of screwing up at the beginning. :)

I'm going to stop this post here because it's stupid long and I'll do another responding to YouKneeK's comments - I'm really sorry I can't write more concisely.... :

Holy halos that was long... I'll try to keep my responses to YouKneeK's really good points much shorter.

Actually buying BL would be a huge deal, would take months, and would require a LOT of discovery, not to mention a negotiated transition plan that would involve some travel for someone and ideally an agreement for transitional training for programmers and DB admins. A lot depends on how well they've documented their builds too (most of the time, in my experience, documentation doesn't exist) and what language it's in. The site would also have to be moved to a hosting company that would do a better job that what's happening now.

1. I know nothing about nonSQL databases either, but Win SQL and Oracle are the two biggest databases in use. WinSQL is cheaper and faster (or used to be) but faster only until you reach a certain size threshold. After that Oracle is a much faster and efficient database. It's also harder and more expensive to find Oracle DB Admins (although my BF is one). Most database can be ported to another but it's expensive and time consuming (but possibly cheaper than finding a db admin for an obscure database type).

And yes, I suspect they wanted to really get the database design right and then got overwhelmed by how hard and how long a process that was and rushed it at the end (b/c people were SCREAMING for it) or they hired someone who really didn't know what they were doing.

2. Whatever they're using for hosting has to change - I'm sorry but there's no way a professional mob is hosting this site; it's too unstable, has no alarms for service outages, no redundancy, etc. And if they're using standards-compliant code/scripting, it wouldn't be hard to move it from Win to Linux or vice versa, but the database would be a determining factor. I'm more comfortable in this area and feel confident this would be one of the easier things to solve/setup.

3. The part of the site that allows the blogging and customisation of the blogging uses Twig, something I've never heard of until I joined here. So someone who knows HTML, Javascript, Twig, whatever they're using for their dynamic HTML... but you're right YouKneeK: knowing how to find a qualified programmer is almost one of the hardest things to accomplish; unless you know what to ask you'll end up with someone who isn't up to the job.

The language (unless we're talking about written documentation) doesn't worry me very much; most programmers - all of them actually - I've ever known program entirely in English (and most of them are Danes or Norse. A few Russians too.). You might get some comments in the code that are natively written, but those could be sorted out easily enough.

To me the hardest questions are these: whether or not BL was bought or a new BL was built, could it sustain itself? And how? I'm not even talking about a profit - could it just pay its own bills? Membership? Ad revenue? A combination of both? If the site had curated ads (books only, no video) what kind of money could it bring in? How much would membership have to cost to offset the bills? Would anyone pay that much? These are the questions that stump me and slow me down...

Reply to post #30 (show post):
MbD -- You will get NO complaints from me on length! ;-)

Reply to post #32 (show post):
lol... thanks! I have a really hard time personally reading really long posts, so I try hard not to write them long. But sometimes there's no avoiding it if you want to be clear and comprehensive.

Speaking of which - another biggie we have to take into consideration: hiring someone who would be qualified to combat robotic spam. As we've seen at GR in the past, that can be a full time job in itself.

And there's the NON-robotic spam. . . . .

Great info MbD, thanks! I never mind reading long posts. Goodness knows I write enough of my own. Finding the time to reply to posts of any length is where I have more trouble. :)

Those are really standard programming languages then, so that’s good. Anybody with web development experience should know HTML and Javascript. I’ve never heard of Twig but, after Googling it, it just appears to be a template engine for PHP. That’s another common language, so it would presumably be easy to learn for people with experience in that area.

I’d be really surprised if the actual programmatic functionality is all handled using Javascript. There’s surely something else running on the server side while Javascript is used for the stuff that’s handled by the browser.

Commenting so that I can follow along with this too! I'm hoping SO MUCH that this isn't necessary but it's better to be prepared. *sigh*

Reply to post #35 (show post):
Agreed, there's a lot of javascript but it can't all be javascript - Ruby on Rails if we're lucky, or another standards/open source framework. Those would be easy to find competent developers for.

In one of those "DOH!" moments this morning I realised one of MT's best friends owns a Web Development Company. A big one. *face palm*. I'm going to ask him to guesstimate database design costs, since I think that might be the most expensive part of building from scratch - that and the web developer who can build the interface between it, the blogging stuff and the dashboard. At least that would give us an idea of what kind of ballpark we're in.

Reply to post #36 (show post):
I'm hoping too Jessica. I love Booklikes.