As a potential user, my interest is in how easy is the system to use. I think a program has to be pretty much plug-and-play with the ability to be more if one desires customization.
That said, I'm not wed to the idea of LJ code; I like it because it's easy to work with, user-wise.
I'd rather learn from LJ's structure and experience and design and so forth. The code is the least useful part of any of that. (As is generally the case with software projects.)
I understand the lure of getting stuck into the technology, but there are so many unanswered questions that talking tech now is like getting pregnant and then fussing over making a restaurant booking for the child's 21st birthday.
Heck, there are too many un*asked* questions at this point.
I'm tentatively in favor of keeping with the LJ codebase, which may come as a surprise to those who know me.
It's not that I don't think that we could write something that's as good or better than LJ. And it's not that I think Django is a bad technology -- I haven't tried it, but I love Pylons, which is very similar.
My worry is more social: reimplementing would lead to vast arguments about what should and should not be changed. The risk of a community collapse is vastly increased when the scope for new design is higher. And if we say that we're simply going to clone LJ wholesale, then there is no point in writing new code.
I am not cloning LJ wholesale, for what it's worth.
It's really six of one, half a dozen of the other whether or not elsejournal chooses to use this codebase; I'm developing it independently of this or any other effort, but if there's interest, I'm certainly willing to take input.
Not that any of that really changes your argument, but just for context...
Not to mention, the LJ code, look and features are what people are comfortable with, which means keeping it might make people more likely to make the move.
Account: represents a billing entity which pays (or doesn't) for service. Has at least one Identity, may have more than one.OK, I've gone and contemplated for a while, and I've come to the conclusion that having multiple identities per journal is a really bad idea, and I'd like to encourage you to stick with LJ's model of "If you want another identity, get another account/journal from another email account
( ... )
For most people, the convenience of only having to enter a credit card number once far outweighs the security. For those who are more worried about security, tho, multiple accounts should be an option, and the security benefits should be well-documented.
For most people, the convenience of only having to enter a credit card number once far outweighs the security.
Well, yes. That's my point. :) That presented with that "convenience", most people won't worry about security and will opt for convenience, without realizing the risk they're running. Which is why I don't think it's prudent to give it to them.
All of which reminds me of the ugly issue of liability and legal structure. So, is Elsejournal gonna incorporate or what?
Comments 27
That said, I'm not wed to the idea of LJ code; I like it because it's easy to work with, user-wise.
Reply
Reply
(If we're going to consider non-LJ solutions, Wordpress MU might also be good. It works beautifully for http://blogs.gnome.org.)
Reply
Do you think it would be better to write this all from scratch or try something like rewriting the LJ code and then building off of that?
Reply
Reply
Heck, there are too many un*asked* questions at this point.
But sure, it's fun to geek out. I do it too.
Reply
Reply
Reply
Ask questions!
Reply
It's not that I don't think that we could write something that's as good or better than LJ. And it's not that I think Django is a bad technology -- I haven't tried it, but I love Pylons, which is very similar.
My worry is more social: reimplementing would lead to vast arguments about what should and should not be changed. The risk of a community collapse is vastly increased when the scope for new design is higher. And if we say that we're simply going to clone LJ wholesale, then there is no point in writing new code.
Reply
It's really six of one, half a dozen of the other whether or not elsejournal chooses to use this codebase; I'm developing it independently of this or any other effort, but if there's interest, I'm certainly willing to take input.
Not that any of that really changes your argument, but just for context...
Reply
Reply
Reply
Reply
Reply
Well, yes. That's my point. :) That presented with that "convenience", most people won't worry about security and will opt for convenience, without realizing the risk they're running. Which is why I don't think it's prudent to give it to them.
All of which reminds me of the ugly issue of liability and legal structure. So, is Elsejournal gonna incorporate or what?
Reply
Leave a comment