Note: This post is based on an old page from the main site that makes more sense here, now that the blog is finally up and running.
Since 2007, I have been a small business owner, operating Colagioia Industries, which allows 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 my 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.
The main purpose of Colagioia Industries is those web services, imagining and discovering systems that make life easier for people. They haven’t exactly turned CI into a dangerous, multinational conglomerate, but they have paid for themselves for extended periods and given me some insight into different approaches to business.
Highlights over the years include…
Consulting isn’t typically my preference, since it quickly gets to be less about the actual work to be done and more about making sure clients actually pay their invoices and getting subcontractors to hit their deadlines. 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 things. And, obviously, there’s also a fair amount of custom development.
I can’t go into much detail on the software development side, due to non-disclosure agreements, but I’ve been able to work in diverse fields such as education, science, logistics, retail, social media, gaming, and gambling.
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 central premise was to give creators a way to distribute their works through a public license to the general public, but to also easily and non-confrontationally offer and negotiate a commercial license where there was interest.
A capability was also built-in to fund a project by the Street Performer Protocol.. Creators could post the completed works essentially in escrow and set a deadline and funding requirement for which the work would be released under a standard and non-discriminatory Free Culture license.
I pulled the plug on Agora/Open (named for sort of an overly-complex pun suggesting a marketplace that was open, but also for open things) shortly after launch, due to the complexity and potential liability of collecting, holding, and distributing 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 would probably be more courageous about this—today, we all understand that payments carry fees and are generally held for a monthly disbursement—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 small 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 average pitch 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 the collaboration aspects of 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 about the potential for liability of an open-licensed content marketplace, the business plan evolved to use Agora/Open as a sort of 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 my payment processing company pulled business out of the United States.
eManagr was predicated on a few simple ideas:
- An organizational model where people can be recruited based on reputation and performance on prior projects,
- 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 the average deviation in scheduling future work,
- Open voting on tasks to prioritize them, and
- Communication with the system via both web and e-mail (with SMS planned), allowing for essentially automated management.
The system had a reasonable-size user base, enough of which paying for the premium plan to keep the server running for a while. I decided not to look for a new eManagr payment processor when Rails saw a rapid series of major security flaws and patches at the same time I was offered an excellent full-time position, so exported data for each user and moved on.
Years later, 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 or took estimate accuracy into consideration.
A Social Me
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 then-new API.
The service 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 uncooperative these social media companies can be, and guessed that the other services would follow wherever Facebook led them. That decision bore out well, given Twitter’s API changes over time, not to mention Yahoo!’s flailing and Google +’s inability 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 is pretty thoroughly opposed to what I want to see in the world, as previously discussed.
I may yet resurrect A Social Me, on day, under a more ethical premise that I have been slowly formulating over the last few years. It would probably revolve more around production than consumption and simple relationships. Plus, I’m fond of the logo, goofy as it might look. 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…not quite a nosedive, but certainly not in a healthy state. It becomes more of a dive in niche markets, though, 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, embedded 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 copies ship in many cases (especially in the case of comic books), downloadable to any device for free. ByPage was designed with comic books specifically in mind.
Let’s be clear: Piracy is a terrible use of time and abuses some creators (though I have no particular sympathy for companies being abused where they abuse both creators and customers), and don’t think anybody should engage in it, 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) buying digital content as downloading copyright-infringing scans. Two publishers agreed, buying copies.
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 has overstock ever been sold at full retail price, except for collectables? For some reason, though, that’s how a lot of publishing works.
(I am fully aware, however, that subscriptions are where the companies all want to be, because it subsidizes less popular 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, ByPage uses steganographic techniques to invisibly add user information into each page image of a download. The result is that, if someone does redistribute the book without permission, 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 purchasing as good an experience as piracy, not to (as mentioned, 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 first change in direction. 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 else like it to this day. The code is old and would need some care, like the other projects I describe, but I would love to see ByPage 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 unless they ask to be interrupted.
- 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 custom 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 correctly, 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.
In many spheres, e-mail has been mostly abandoned by users shifting to forums, chat and 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 all of this (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 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 place 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. I admit that I am also kind of proud of the angry, screaming bicker-monster mascot(s), Bickie. The day I need to sell merchandise, he or they will be everywhere.
I sold a few Bicker servers as appliances, which was nice, but I have recently been working on reinventing Bicker as an open source project! You can follow the progress with the Bicker tag and even contribute on GitHub.
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—designed 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 acquire 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 in their own posts.
Credits: The header image is Orrery designed by William Pearson, made by Robert Fidler, 1813-1822 by the Science Museum Group, made available under the terms of a Creative Commons Attribution-Share Alike 4.0 International license.
Tags: software technology meta