Since 2007, I have been a small business owner, operating Colagioia Industries, allowing me to experiment with new technologies and business models while also keeping a foot in the technology world during times when I’m between “real” jobs or the day-job work isn’t particularly technical. In plain English, this means that I pick up the occasional consulting job when something interesting falls into my lap, while also providing me with an excuse to develop and publish web services.
(Don’t care? Head back to the main page)
Consulting isn’t always my preference, since it quickly gets to be less about the actual work and more about making sure clients actually pay. But once in a while, a project is too compelling (and/or pays too well for the work involved, frankly) to pass up. That’s all to say that, if you try to contact me with work and I don’t get back to you immediately with a quote or turn you down, please don’t take it personally. If I know anybody looking for work, I’ll try to introduce you.
Obviously, that work varies a lot. Over the years, I have been brought in to write code, of course, but also to write documentation, training material, and web copy, teach classes, configure home automation systems, research intellectual property, and even stranger.
The main purpose of Colagioia Industries is web services, imagining and discovering systems that make life easier for people. They haven’t exactly turned CI into a dangerous, multinational conglomerate, just yet, but they have paid for themselves for extended periods and given me some insight into different approaches to business.
Highlights over the years include…
My original brainstorm in late 2007 was a website where people could post art and code projects they wanted to share, sell, and license. The premise was to give creators a way to distribute their works through a public license to the general public, but easily and non-confrontationally offer and negotiate a commercial license where there was interest.
The capability was also built-in to fund a project by the Street Performer Protocol.. A creator could post the completed work essentially in escrow, and set a deadline and funding requirement by which the work would be released into the public domain or a liberal Creative Commons license.
I aborted Agora/Open (named for sort of an overly-complex pun suggesting a marketplace that was open, but also for open things) before launch, due to the complexity and potential liability of distributing the money. In particular, the cases where projects were multi-generational derived works that required royalty payments to multiple creators concerned me in a world where digital payments were not yet straightforward.
Today, I might be more courageous about this, but I also think that crowd-funding sites like Kickstarter (launched in early 2009, if anybody was keeping track) fill most of this niche, albeit imperfectly.
On the other hand, there may still be a role for such a thing. Another major aspect of Agora/Open was searching projects by aspects that were relevant to the user, such as duration and frequency for audio, dominant colors for images, and so forth. As that analysis has gotten better, and as payment processors like Stripe have become a better solution than those like PayPal, it might yet be more useful to have a central clearinghouse where creators can have an official outlet for their digital works and attract licensing offers.
Time will tell. In the meantime, however, Ruby on Rails has changed significantly and so the original code won’t work, but the main page still waits for a viable product and better graphic design at Agora/Open, so it may yet return…
I anticipated a problem with Agora/Open, which was coordinating effort when multiple creators were working on mutually-derived works. For a world where organizations and deadlines are fluid but important, there are no tools to help. That is where eManagr would have come in.
Initially I intended for Agora/Open and eManagr to be complementary both for the users and in terms of revenue. However, as I became increasingly concerned over the revenue potential for an open-licensed content marketplace, the business plan evolved to use Agora/Open as a loss-leader to draw people into the management system. Then I abandoned A/O completely (including for reasons described above) to work on eManagr as the “flagship” product. It worked, and the revenue covered the server bill until the payment processing company went out of business.
eManagr was predicated on a few simple ideas:
An organizational model where people can be recruited based on reputation and tracked performance,
An work-estimation system that required drilling down to precise enough detail to increase the accuracy of estimates,
Tracking the accuracy of estimates per user to use them in scheduling future work,
Open voting on tasks to prioritize them, and
Communication with the system via both web and e-mail, allowing for essentially automated management.
The system had a reasonable-size user base, enough of which paid to keep the server running for a while. I closed eManagr when Rails saw a rapid series of major security flaws and patches. Too much of the code relies on outdated behavior and would need a rewrite, so I sent the active users their data and shuttered the site for the duration. It will surely return, as I haven’t found any other project management system that proactively monitored projects.
Around 2009, I worked on a gig to help a company monitor its social networking “buzz,” creating a system to scrape user profiles and present the changes over time. After a change of direction on their end, they only wanted to buy a product or service, rather than code to maintain. So, with their approval, I took the existing code and rolled it into a web service and tweaked it to understand the difference between social relationships and business relationships.
(They then reorganized and decided they didn’t want any of it, but that’s another and far less interesting story.)
I closed the doors on A Social Me when Facebook started chasing after developers for scraping publicly-available information instead of manually (no stored passwords) logging in to use their awkward API. (Hint to platform developers: Nobody wants a more difficult way to get less accomplished. Yes, the flexibility cuts into your ad revenue in the short term, but more users come in for more ads.)
The business could potentially have succeeded without Facebook…or by only working with a regular Facebook log-in and app, but that seems to defeat the purpose of automation. However, it reminded me how fickle and non-cooperative these sorts of companies can be, and guessed that the other services would follow wherever Facebook led them. That turned out to not be entirely true (or at least premature, given Twitter’s API changes over time), but Yahoo! has since done a lot of damage to their position in social media, as well, and Google + couldn’t seem to get its act together.
Plus, a few years down the road, I saw Klout (roughly the same principle) and I regretted closing a lot less. I realized I had developed a system that worked by manipulating customers into being even more anxious about their social status than they already are, which doesn’t really fit my personal mission statement.
I may yet resurrect A Social Me under a more ethical premise that I have been slowly formulating over the last few years, probably revolving more around production than consumption and simple relationships. Plus, I’m fond of the logo. The very old Ruby on Rails code will need to be rewritten from scratch, but anybody who wants information on a return can sign up at A Social Me.
For years, I have been watching publishing in a nosedive. The dive is even steeper in niche markets, despite the power of the Internet. The dive is steeper yet when it comes to content that is ideal for the Internet, like comic books.
The problem is that publishers want a stranglehold on everything. But when it comes to digital, they’re competing with piracy. And while companies try to restrict access (DRM, Flash-based players, lack of ownership, subscription fees, and draconian rules), they fail to realize that they’re competing with high-quality scans delivered before the paper comics ship in many cases, download-able to any device and free.
Let’s be clear: Piracy is a terrible use of time and abuses some creators (though I have no sympathy for companies being abused where they abuse both creators and customers), but it won’t ever go away. Pass all the laws and develop all the digital locks we want, but we can’t stop a dedicated “extra-legal archivist” (to coin a phrase) from scanning a book or taking screen shots and posting the files where others can download them. It’s impossible, even if we allow the companies and law enforcement to trample on legitimate activity in the process.
So, I spent some time messing around with sales and distribution models along with reviewing discussions I had about Agora/Open (where the goal was to sell free things), and ByPage was the result. I believe it can resolve the corporate fears while being as appealing to consumers (in the right ways) to buying digital content as downloading copyright-infringing scans.
Pricing, I believe, needs to scale with usage. ByPage doesn’t support subscription fees (though that would be trivial to add). Instead, customers pay for immediacy, full cover price for a new book, with the price decreasing every day or week to a final “back stock” price for the title. When have back-issues ever been cover price except for collectables?
(I am fully aware, however, that subscriptions are where the companies all want to be, because it subsidizes unpopular activities, makes revenue more predictable, and people forgetting to cancel their subscriptions is free money. Still, it’s a bad move that only augments the problems with piracy. Making someone who only has limited interests pay for everything is losing business in the long term.)
In terms of distribution, I devised a very simple, indirect DRM-like mechanism that actually solves a real problem without creating new issues. Rather than try to build a system to restrict who and when a reader can read their book, which does nothing but generate ill will and encourage more piracy to bypass the locking, I add user information into each page image of a download. The result is that, if someone does redistribute the book, the publisher can download a copy for simple analysis. That provides the identity of the miscreant, and their account can be blocked (or charged) without damaging the experience of any legitimate customer.
Yes, of course, someone could alter their pages to bypass or scramble the marking, but that degrades the image, making piracy a less useful way of reading along. The point is to make purchase a better experience than piracy, not to (impossibly) eliminate it altogether. People will pay for a good product they can use the way they want.
Finally, for marketing purposes, I have code that reduces the size and color palette of each page, so that potential users can get a quick sample of the story before they spend any money. If the draw is the story, let people read everything up to the ending. If the draw is the artwork, let them see the whole thing. But degrade the experience so that it’s not a replacement for the real thing. (I modeled the idea after flipping through a book at the store, where you can see whatever you want, but you can’t take it all in.)
If any publisher wants to tinker with the idea, I happen to still be interested in seeing this set in motion, since there is nothing like it to this day. I would love to see it blow the doors off the big businesses for some small-press company.
To this day, despite all the propaganda against it, I still believe that e-mail is one of the most effective communication tools available.
It doesn’t demand anybody’s immediate attention.
It can be completely casual or relatively formal.
The format is extremely lightweight in terms of storage (plain text) and transmission (momentary connections). And,
The message is editable by the recipient, making the context of replies easy to manage.
Today, people barely recognize any of the potential in e-mail. They “top-post” replies and yet carry generations of old replies in the body. HTML mail buries the message in formatting that is often both ugly and worthless. People get angry when the recipient fails to reply immediately. Barely anybody has ever used the BCC field, instead plastering every address across the Internet. And yet, with all this, e-mails still carry no content, with a shocking number of “me too” and “yes” messages that fail to attach to any context, especially with the rise of phones and tablets.
(I have a special hatred for the “sent from my super-awesome, expensive toy computer that I love more than I want to pay attention to what you have to say.” Signatures in private e-mail are bad enough, but when they’re advertising, it’s just obnoxious. Also, if you use the device in a professional context, it screams “playing hooky, don’t expect a coherent response!”)
In many spheres, e-mail has been mostly abandoned by users shifting to forums, instant messages, text messages, proprietary private messages, and web-mail, not to mention weird experiments like Google (now Apache) Wave and inexplicably using wikis to host discussions. Even newsgroups also appear to be back, in some circles.
Therefore, I tried to re-invent e-mail (the right way) as a web service with e-mail facilities, to replace a dying e-mail discussion list I was involved with. I named the result Bicker.
Bicker (not currently online) combined the idea of a date-sorted topic/subject list from both e-mail clients and forums, but with the added idea that the “thread” is now an inherent part of each message rather than a structure imposed on messages. Once someone posts, another user can click on any punctuation mark (the obvious time to interrupt a train of thought) to insert his or her in-context response, nested in a readable way.
The result is a natural conversation flow that can occur in (almost) real time or completely asynchronously.
When I go back to it, a module I think is important is to connect it to e-mail, so that someone can join the conversation without worrying over a persistent network connection. Once e-mail can be “bridged” to the web, it will at least make me happy.
I admit that I am also kind of proud of the angry, screaming bicker-monster mascot(s). The day I need to sell merchandise, he or they will be everywhere.
Over the years, I have at least briefly looked at publishing different games, selling “social networking appliances,” creating digital-and-analog scrip/coupon systems that could be used in place of money, and a crowd-sourced news system accountable to its readers and only its readers.
Some of them are obsolete with more recent competition, like OpenKash—looked at as the economic problems of 2008 were coming to a head—doesn’t have the technical sophistication or global appeal of Bitcoin. Some are nearly impossible to fund reliably, such as Fixit News needing to be free to get readers while still wanting to pay people for reliable reporting, without taking on any advertising. But some might be reconditioned into useful products at some point, and I may publish some others (including some of the bigger projects listed above) under an Open Source license in the near future, at which point I’ll discuss them on the Software page.
Back to the main page