Open Source Precursors

Submitted by Morbus Iff on Thu, 2003-07-10 13:18

One of the projects I've worked on recently approached me concerning open sourcing the code I'd written (always a happy start to my day). He opened up with "we have a system and other $businesses don't, but might want it" and continued on with what it might entail, the process of doing so, etc. As I did with my response to a friend concerning technical documentation, here's what I sent him back:

Your first comment is the most crucial one, and determines the fate of the project, really: if people don't want the code, then a lot of work would be wasted getting it into a place that'd make it usable. Do $businesses even want the code? Have you asked? Have you checked other sites and seen what they're using already? Do they have features that our current backend doesn't? What are their technical capabilities? Can they even run our code?

The next most important question: what does $yourcompany get out of this? Are you prepared to answer tech support questions from other $businesses? Prepared to discuss design issues on why you did things this way, and not that? Prepared to say "welp, I can put that feature on the todo list, but since we're never going to use it at $yourcompany, I doubt it'll be anytime soon." What happens if someone uses your code, and it magically deletes all their data? What are you going to say to the people who don't have proper backups?

Are you prepared for the open source community to look at your code, discover some huge security hole, publicize it on heavily-read security lists without telling you, and then scramble to implement a fix before the hordes of script kiddies come knocking? There are certain rules of ethics in reporting security vulnerabilities, but you inevitably get the idiots who find it more important to announce how smart THEY are before they give you a chance to prove how smart YOU are.

The above are all questions that need to be addressed. I'm a huuUuge fan of open source, and I need to protect against the common suffrages:

  • lack of usability ("here's the code, there's no docs, whee!")
  • lack of support ("here's the code, i'm in Maui, whee!").
  • lack of forethought ("well, i thought i was doing the 'right thing' by making it open source, i mean, that's the new wave, right? how can something so good require forethought?")
  • lack of community (where can people talk about your project? how can they announce their changes, code tweaks, problems? where can they report bugs?, how do you announce updates?).
  • lack of development (releasing code is nice and all, but if it's just gonna sit there and stagnant, it may not be the most ideal. if you DO just want to release one version of code, and let be what may, then you can ignore the support or community aspects: open source projects that never update are often ignored for being "out of date", whatever that means).

From an implementation standpoint, there are a few things I'd suggest need to be done before announcing, or offering the code to other people:

  • solve "lack of usability". I know the code, you know the implementation. "documentation" consists of you asking me a question, and me writing up some insanely long email like this. before the code would be usable, documentation would have to be written, covering areas of database layout, how to administer, how to customize the templates, how to install the project, how to implement a database backup system, etc.
  • solve "lack of usability". currently, the templates all look like $yourcompany, they're tweaked for $yourcompany, blah blah blah. to give people a good base to start off with, attractive and anonymous default templates would need to be created, that they can customize at their leisure.
  • solve "lack of usability". the database is currently PostgreSQL. as we've discussed in the past, it's probably a better solution to make the default database MySQL. from the standpoint of new users, MySQL is more widely implemented on generic webhosts than PostgreSQL is.
  • solve "lack of support and community". create a project over at sourceforge.net, with mailing lists, bug trackers, etc., etc. while you won't know if the code is a "hit" for awhile, and the features could lay dormant, you don't want to stymie early adopters by not having an outlet.

Thoughts?