jducoeur

Today's project is starting to implement Multiple Choice. (AKA enumerations.) The concept has existed for a long time, but it's a manual PITA to create a multiple-choice Property, and I'm tired of it, so I'm turning it into a proper Type. That's complicated, but so far well in hand.

But as part of it, I've been staring at all these places that are using the Link Type, which is the underlying basis of Multiple Choice. Link is *the* most important Type in Querki -- it's a reference to a specific Thing, basically the equivalent of a "pointer" in most programming languages. (Multiple Choice is implemented as a Link Property to a particular Model, whose Instances are the options to choose from. That's very powerful when you need the power, but like I said, a pain in the tuchus to build one; time for a proper wizard that hides the details of what's going on for the common cases.)

Anyway, I am suddenly realizing that "Link" is also a terrible name. Specifically, while it is *technically* quite accurate, that accuracy is mostly irrelevant: the pointer gets auto-dereferenced in almost all circumstances, so the fact that it *is* a pointer is rarely useful to the end user. Mostly, it's taking brain space for no good purpose -- as far as the user is concerned, it's just a Thing. So I should probably change the name of the Type.

I can't just call it "Thing" -- that's already the base Model for the entire Querki universe, and is quite central -- but I'm tempted to use "Something". That's vague, but that's kind of the point: when you're referring to a value of type Something, it can literally be any non-primitive value in Querki. (Including Properties, Types, People and so on.) In practice, you can restrict the Model that a given Property can point to, and we'll eventually enhance the functions to preserve this typing in the code -- basically implicit generics -- but conceptually, it's just "Something".

The vagueness kinda bothers me, but I don't have a better idea yet, and it seems to relate in an appropriate way to the concept of "Thing" -- a value of type "Something" contains one or more Things. Opinions?

Today's Querki release has one major change: the first appearance of the "Apps" menu. It's hard to overstate how important that is. When I originally figured out what an "App" would be in Querki, three and a half years ago, I realized that I had a viable business here, not just a tinkerer's toy. It's taken all those months to get to the point where the rest of the system is solid enough to start implementing them. So pardon me a burble about what the word "App" means in Querki -- how it works, and where it's going.

The thing here is, Querki doesn't tick like most platforms. There's an almost universal assumption in the programming industry that "code" and "data" are fundamentally different. A program is built by a programmer, who writes code; he then gives that program to a user (often treated as a Dumb User), who puts in their data. That dichotomy underlies most of the history of the field, and it's central to the Priesthood of Programmers that you see even today.

And yes, I use the term "Priesthood" very deliberately. I mean, think about it. It's a body of specialists who understand the arcane rituals of intercession between those Mysterious Beings (computers) and ordinary mortals, to beg said Mysterious Beings to make their lives better. Many people want to join, in order to advance themselves. The only real difference is that you call a Priest when *you* are dying, but you call a Programmer when your computer is doing so.

Querki is, at heart, a rebuttal of the Priesthood model. The whole idea is to make it as easy as possible for everyone to manage their own data the way they want to do so, not constrained by some programmer's preconceived design. It's a Database as Wiki, trying to demystify things as much as possible, with an absolute minimum of Programming.

All that said, not everyone *wants* to come up with their own designs. If I build, say, a kick-ass Historical Recipes Space, and you like it, you don't want to go to all that work yourself -- you just want your own copy of how it works, so you can plug your own recipes in. You might want to tune it and tweak it a bit to your own needs, but basically I want to be able to share my work with you. That's where Apps come in.

So: A Querki App is a template, lifted out of an existing Space, which other Spaces can share. Simple enough, but there are a lot of implications there, so let's unpack it.
( Working with Apps in Querki )

Conclusion

Ultimately, Apps are the reason why I believe Querki is going to be a mass-market system. While it's already great for anyone who knows how to "think in data" and enjoys fiddling, most people just want something that works, that they might want to tweak a little but mostly just want to use. In that respect, Querki Apps are a lot like the ordinary ones: people who just want to use them can just use them. The difference is mainly creation-side: an App that would take days, weeks or even months to build on a conventional platform can often be built and shared in an hour on Querki.

There is a *ton* more to do yet, before the above vision is fully realized. Some of the key steps in the coming year include:

• Scalability -- moving Querki into the cloud, so that it will scale properly and quickly when needed.


• History -- changing Querki's internal architecture to make it nearly impossible to lose data, so that you can Code With Courage.


• Social Network Integration -- at least Facebook and Google+. (I'd love to have LJ integration; we'll see if that's practical.)


• Fleshing out the above workflows, to make App maintenance easy.


• And probably most important: improve the "user onboarding" experience. The first hour of using Querki is still *way* too mystifying -- fixing that, providing an easily-understood entry ramp, is probably the most important "feature" yet to come.

But even with all that on the horizon, I'm very excited: after all this time, Querki now looks more like the long-term vision than not. It's becoming ever-more-useful, and Apps will go a long ways towards introducing it to people.

Questions? Comments? I would *love* to burble more about this, if anyone's interested...

[Mostly for the techies]

I was just reading this recent article in TechCrunch -- it's light on detail, but makes the likely-correct point that APIs are going to become ever more important in the industry in coming years. So I'm pondering: what should Querki be doing with them?

At the highest level, the notion's been around for a while -- I think Galen mentioned the idea of API integration a couple of years ago now -- but Querki's original architecture wasn't API friendly because the QL processing pipeline was too synchronous. Now that that's fixed, I don't think there's any reason we *can't* build API integration into Querki, allowing a Querki Space to call APIs of external services. I'm just not sure what it *means* yet, and my rule for Querki is that I don't build features until I have clear use cases.

(NB: I'm specifically talking about Querki Spaces calling external APIs here. Querki itself already exposes an extremely rich API -- the rewrite I've done over the past year effectively means that Querki is *entirely* API-based, and simply provides a standard Client for working with those APIs. They're nowhere near stable enough yet, and are completely lacking stuff like documentation, examples, validation suites and all those elements you need in order to make an API real, but under the hood everything is now driven by a straightforward JSON API that you can code to.)

Anyway: I'm looking for ideas. Querki by now makes it fairly easy to build Spaces for your data needs; my current Spaces include things like:

• Kate's Gallery of Cross-Stitch Projects


• LARP development and management


• The public Period Games Homepage, with links to a zillion pages on the topic, organized by Game, Source, Topic and so on


• The new (still in progress) Carolingian Cooks Guild database of recipes


• My personal Filk Songbook


• House Lochleven's Inventory Management Space

Etc, etc, etc -- basically, small collaborative websites that let you collect, organize and share information about some topic.

The question is, in what ways would API access make this better? What could you do more easily in this world, if you could, reasonably easily, tell Querki to go out and do *something* with a particular API from some other service?

None of this is going to happen soon, mind -- I have lots of more-critical irons in the fire at the moment. But I'd like to add some examples to Querki's Use Cases, to help understand where we should eventually be going with API access.

So the floor is open for brainstorming. Anybody got suggestions? Anything data-centric you've always wanted to build, that would work best if you could mix in specific outside data?

Just came across this interesting article on Medium. It's worth reading through -- it's not horribly long, and it points out that your music-streaming dollars (assuming you use one of the music-streaming services) probably don't support your favorite artists to the extent you expect -- but the tl;dr is that if you're a light user, your subscription money essentially winds up getting hijacked by the heavy users. And potentially, by fraudsters. I'm not sure I'm entirely comfortable with the article's response to this (which is to essentially democratize the same fraud in protest), but it's a good point, and worth knowing about.

I confess, I'm a bit appalled. I had been just sort of assuming that subscription money was allocated according to what the article describes as the "Subscriber Share" method, because that's pretty obviously the *sensible* way to do it. But the services are apparently lazy, so they wind up using the "Big Pool" method instead, which leads to this hijacking by the heavy users. Basically, they've incentivized people to stream music 24/7, which is kind of idiotic but typical of the modern Internet company.

I don't know if "Silent September" is going to get enough peoples' attention, or whether it will change the companies' behavior even if it does happen in a big way, but the article's main point is correct. Companies like Spotify *should* be allocating their funds using the Subscriber Share method. As it stands, a lot of artists are getting badly ripped off by people who are gaming the system.


Why is this relevant to Querki? (Besides the fact that everything relates to Querki in my head nowadays.) Don't take this as gospel -- it's business-plan stuff, and subject to change -- but one of my medium-term goals is that Querki should have revenue-sharing for apps. That is, we'll be adding "apps" -- socially-shareable simple applications within Querki -- later this year. Since Querki is subscription-based, apps aren't going to be individually priced (at least mostly not; we might add that later, but separately-priced apps are tricky to fit into the business), but I do want folks to be able to make some money off of their work. So the current plan is that we'll allocate a portion of each user's subscription fees for apps, pro-rated based on how much that user uses that app. (Using the "Subscriber Share" approach, because like I said, it's the obviously-correct way to do this.)

We'll see if all of this passes a sanity-check: there are all sorts of challenges (a few technical, mostly legal) to deal with here, and it's not going to happen for at least a couple of years. But the hope is that, just as Querki makes it Very Very Easy to create new Spaces, it'll also make it similarly easy to make at least a bit of money off of apps. I don't expect many people to get rich this way, but I figure that if you can build a useful app in a few hours, and get an income stream of a few hundred dollars a month from that, that's not a bad deal...

[tl;dr: Querki finally enters Beta today. I'd love to have people come try it out; drop me an email or comment here if you'd like to try it.]

Have you ever ridden the Superman coaster at Six Flags New England? (Which I gather has been renamed Bizarro.) The first time I tried it, I saw the sign out front, which said that the coaster was 208 feet high, and started with a 221-foot drop, and nervously figured that it had to be a typo. So we went on the ride, climbed up the first hill, got over the top, and realized (a) that the initial drop is *straight down*, and (b) it was straight down into a big black hole in the ground. No typo. So there was the OMGOMGOMGWe'reGonnaDieAhhhhh, followed by the exhiliration of shooting out the other side of the hole into the air.

That's kind of what the past six months have been like.

It's been just about three years since I tendered my resignation from Memento and said, "I need a personal project to work on", and exactly 30 months since I started coding. There have been a lot of ups, downs and learning experiences along the way. The past six months have been *nuts* -- it was six months ago tomorrow that we incorporated the company, and I've spent most of the time since then rewriting the UI to make it Not Suck. But today, it's time to shoot out the other side.

As of today, I'm officially declaring Querki to be open for Beta. I'm not going to claim that it's *done*, mind -- I've got a list of bugs to fix as long as my arm, and an absolutely enormous list of enhancements I want to make. But we're finally up to the point where I think the process of building a Space isn't half-bad, so it's time to get more people in to start using it for real.

I've just finished the first draft of Learning Querki, a short book that teaches how to use the system, with copious examples and illustrations. Impatient engineers may still want to use the much-shorter Querki Quickstart, but if you prefer to know what you're doing before you start kicking the tires, take a couple of hours to read Learning Querki. (And if you've been wondering what the heck I'm talking about, I recommend the page What is Querki?, at the beginning of Learning Querki.)

Today, I'll be upgrading all of the existing Invitees to Full User status, and inviting everyone who has previously asked to join. That's still only about 50 users, though, and I'd like, over the next few months, to get closer to 500. So if you'd be interested in using it, please comment here or send me an email or DM. (I will need an email address for the invitation.)

Folks with a little technical background should be able to jump right in. Those who don't, but who have interesting projects, please talk to me -- I'd be happy to help build a Space for you, as I have time available. While I'm going to be working on Scalability for the next few months, in the meantime I want to get folks using Querki for real, and telling me what works and what's broken.

Or in other words: now that the safety rails are mostly working, I'm looking for company on the roller-coaster. Please join me there, and welcome to Querki...

[Apologies to my friends at Google, but this has been nibbling at the back of my mind for a long time.]

One of the real concerns for Querki, pretty much since the beginning, is the question, "But what do you do when Google decides to compete with you?" I mean, my company is about data -- it seems likely that if I succeed, Google will, in some fashion, try to compete. And the obvious assumption is that Google would squish me -- this is, after all, why I quietly shut down the CommYou project when Wave came out, since I wasn't prepared to take on Goliath.

And the thing is, by now I have a clear rebuttal to that: Google competes with *everybody* -- casually, with no long-term vision, and eventually drops most of those projects on the floor along with the user data. This is why I've been furious with Google for years: after I shut down CommYou in the face of Wave, they then proceeded to kill Wave off a year later, instead of fixing the idiotic design mistakes they'd made that made Wave so hard to use. And they keep doing this, over and over again -- today's version is the announcement on Friday that they are killing off Google Code. Once again, they came up with a product to compete in the marketplace, never took it seriously enough, and eventually decided that they weren't sufficiently interested.

(Really, the degree to which Google behaves like a bright nerd with ADHD is sometimes disturbing.)

I have no idea how to turn this into a marketing message, but it's something I'm sticking in the back of my head. Querki *exists* for the purpose of this project. Frankly, I have quite deliberately rebuilt all my own personal data around Querki -- everything from my shopping list to the Period Games Homepage -- so that I can say with a straight face that I am invested to my eyeballs in the success of this project, not just on a business level but in the degree to which I *personally* need to keep this up and running and useful. Google's never going to do that: as far as I can tell, there is no project (aside, of course, for search) that Google institutionally *cares* about, even its much-ballyhooed front-and-center projects like Wave and Google+. (Which is also, according to every rumor, getting gradually dismantled.)

It's not a complete marketing message in and of itself, but it's a start. And it's one of the reasons why I am leery of taking too much outside money, and putting the company in debt like most startups. I'd rather build a slightly more modest business slightly more slowly, that is running in the black as early as possible, so that I can quite honestly say that Querki is sustainable and stable in the long run, so it's a safe place to put your data -- and that Google's track record basically says that it isn't...

Just a quick pointer, for anyone who is interested and isn't already reading over there: after several months of quiet, I've just done a post to the Querki Development Journal, with the current state of things, including new features and talking about the new Querki Client.

And for anyone new to following my LJ: all the detailed posts about the evolution of Querki, including a fair amount of my technical natter, is over in the Development Journal. If you're at all interested in the project, I strongly commend it to you...

The UPS guy just rang the doorbell; the box he was dropping off turns out to contain my new business cards.

On the one hand, I am painfully aware that they are non-mission-critical at best, and self-indulgent at worst. Getting the bloody beta done is what really matters at this point.

But still -- this is the first time one of my projects has been real enough to need professional business cards. Heck, this is the first time I've *had* business cards in, what, over ten years? I don't recall ever getting them from Memento, and maybe not from Convoq, although I do have a leftover (and possibly never-used) box from Convoq's original identity of Applied Messaging. And really, those projects never needed business cards: I was an in-the-trenches engineer, only occasionally interacting with real customers. (And while I did make a few up for CommYou, they were just inkjet-printed on Avery stock, which really is not the same thing.)

This time, though, it's all my baby, and I expect to actually go through this original order of cards pretty steadily as I talk to folks. (This was driven home by my Scala.js talk the other week, when I realized that I *totally* should have had a pile of business cards in front of me.) So Aaron and I sat down last week to talk through layout (he has more visual-design experience than I, and the right tools), and I just got them: nice heavy stock, glossy printing and all. They're pretty spartan as these things go, but that reflects the general Querki aesthetic of focusing on the relevant data instead of a lot of glitzy frou-frou.

Don't be surprised if I press one on you, and please pass it on if you find someone who might be interested. As beta approaches, it's finally getting to be time to talk this up properly...

... because a real one costs real money. But speaking of the company: as of yesterday I am officially CEO and President of Querki Inc., an honest-to-God C-corp registered in Delaware and all that. In a few minutes, I head out to open the company bank account. Now the roller coaster begins to gather speed...

+ We're finally moving towards properly incorporating Querki. This is a very big deal: I've been holding off on inviting more people to come play until we incorporate because let's get real -- that would be deeply stupid from a liability POV. Once this is done, I'll be a good deal freer about invites. (So far, there are only about 20 users, most of them very close friends of mine who I trust.) Mind, the system still needs a lot of work, but for those willing to brave the bugs and UX weaknesses it's getting pretty useful.

- Wow, creating a C-Corp involves reams of paperwork: I am slowly working my way through 15 draft documents they sent this morning. Granted, it's almost entirely boilerplate, but I actually have strong opinions about some of the standard boilerplate, and want to make sure that I'm not signing anything I disagree with.

Points to my lawyers for having a standard-boilerplate inventions clause that is actually reasonable (I spent fully three weeks negotiating this particular point before joining Memento), but I still need to work with them to get the non-compete and secrecy clauses right. I'm trying to adopt a firm principle of not having any standard company documents that I would be unhappy about signing as an employee, and that means being just a tad less paranoid than average.

Oh, well -- a few hours of eyestrain-inducing reading is well worth getting past this milestone. Somehow, making the company official makes the whole project feel quite a bit more substantial...