We had a chance to think about how we will be going about open sourcing our project. There were a few primary concerns:
- Picking a licence. (GPL? MIT? What’s the difference?)
- Modularizing our work. (Create a cohesive pre-built package of software to make it convenient or break it into as many libraries and pieces as possible to make it customizable?)
- Naming it
By far the most challenging part was naming the project. When I think of software I’ve used in the past, the ones with good brands stick out to me most. Adobe Photoshop comes to mind, but that’s probably just because of how massively popular that software is. I remember other software too. I remember Nero Burning ROM. Remember that? Back in the day when you needed specialized software to burn a CD. Err, back in the day when you actually still used CDs? Why do I remember this piece of software. And why did they call it “Nero” Burning ROM? Well, it all comes to the Roman Emperor Nero. During his reign, Rome experiences a great fire and it *burned*. Perhaps “ROM” is even an allusion to “Rome”. They used a historical figure on which to piggyback and gain some brand recognition. Nero Burning ROM was closed source software, but I think this approach may still work well for us.
Our software learns about users. It builds profiles of them based on what they do on the website (or other medium, should the software be extended in the future). We found out that Gaius Marcius Rutilus (let’s call him Rutilus for short) was the first censor of Ancient Rome. He carried out the first census. Given that censuses are all about learning about the people, this seemed fitting. Rutilus isn’t a household name, like Caesar or Nero, but we’re getting there. We found that any portmanteaus of key words we chose to use (think products like “Elasticsearch”) were already taken, or didn’t even roll off the tongue very well. So far, we’re thinking of naming the software after Rutilus.
Licencing ended up being a bit of a challenge to understand. After getting a better grasp of the differences between the various licences, we settled on either GPL or Apache. We want GPL because we want the software to be free as in freedom and for it to stay that way. However, we do have to beware its “viral” clause. Put simply, if you choose to use GPL software in your own software, you may or may not be forced to release all of your own software as GPL too. And the difference is subtle, making this decision scary to make:
- If your software “links” to GPL software, you must release your software as GPL. Linking means merging it in… Importing a DDL for example. They consider this improving the GPL software, so you must release your improvement under the GPL too.
- If your software “interfaces” with GPL software, you are *not* required to release your software as GPL. Interfacing means using the GPL software’s features through its own public interface/API. Interfaces can be socket connections, so TCP or HTTP. For example, you choose to use MongoDB as your database. You didn’t extend MongoDB. You didn’t create software that MongoDB came to rely on. The viral clause doesn’t apply. Your software is yours and you can choose your own licencing, even choosing to keep it closed source and use it commercially.
Apache licence makes it clear that commercial use of the software, even in situations where you’re linking to it, is acceptable. It’s a more “permissive” licence. Because we’re still early in the stages of deciding how our software will be broken apart and used by users, we’re leaning towards Apache right now, since it would avoid us thrusting the GPL’s viral clause onto our software’s users. However, if we’re confident as we release it that it can be interfaced with through public APIs, then we can safely release it as GPL.
However, there’s no current user base out there. The Bootstrap and React example works because they both have solid bases. Without a solid base, who would develop that “glue” for the parts of our framework so that it becomes useful? It would also be a lot of work to set it up. It takes away from the convenience of what our software could do for users, and would make it harder for them to get a good mental grasp on what it can do for them.
Another approach would be to take the work we’ve done, which includes implementations of the idea using a particular database (Mongo) and particular web server frameworks (Node.js, Koa), and package that all together. Users would have to live with our chosen technologies (unless they recreated an entire module in our package), but they would have something that with minimal configuration, would “just work”, and begin collecting data on their users and providing useful analytics tools and building the profiles of the users that are ready to plug into recommender engines, etc. Given that there aren’t many people out there to support the software, we favor this approach, since it would show off what it can do easily, which would probably help it draw in users and contributors more quickly.