Snip-snip-snip–
Snipt!
No, this shouldn’t be confused with SnipSnap… 
Snipt is a new Web-based service that has a promising slogan: “long-term memory for coders”. The premise of the offering is to allow coders (developers, programmers, enthusiasts, etc.) to store their code snippets online and, presumably, to also share them with others.
Clearly, Snipt has entered into the sphere of influence that has traditionally been populated (and in some cases, dominated) by wikis, code repositories, code portals, code management software, knowledge base cores, and bulletin boards. It has the glamor of fun that Twitter has, but whether it will survive past its initial year of gee-whiz into its maturity phase as a stable work-horse product for the masses is anybody’s guess at this point. 
Management Perspective
Snipt represents a curious touchpoint for IT and development managers and directors.
As code becomes more streamlined over time, it would be easy for a coder to place proprietary code or restrictive open source licensed code onto Snipt, which may be inadvertently or deliberately shared. Does this make Snipt a vulnerability that leading-edge tech firms cannot afford to be exposed to?
Also, should corporate developers be allowed to use content from Snipt? Should Snipt’s TOS be more strongly worded to prevent ambiguity? How does licensing enforcement work for large code blocks?
Hmm… Definitely something to consider. If your organization does not have a clear and concise policy of using external code and exposing corporate code to the public (like a vetting process or scrubbing automation, for instance), this is yet another reason to formulate one.
March 11, 2009 Clarification Update: To be clear, the “Snipt” referred to in this article is actually Snipt.net.
{ 2 comments }
Hey there!
Nick Sergeant from Lion Burger, here (the guys behind Snipt.net). We’ve actually seen a few requests come through about licensing requirements on an individual Snipt, and think it would be a strong feature.
Right now, we’re plowing through a public API for third-party devs to build apps on top of Snipt, but we take community feedback seriously, and will try and squeeze the licensing thing in soon.
Thanks for the writeup!
Nick Sergeant
Nick,
Thanks for reaching out and commenting about the concern I raised in the post.
I think there’s a lot of potential for Snipt, but corporate dev needs often supercede the wondrous new online tools and services that are readily available in the Internet at large. And that translates to whether a project gets done in a few hours, or a few days, or a few weeks, or several months…
The third-party dev API definitely sounds interesting as well. I’d see how a team would be able to use some sort of API to bind their code collaboration tool (like one of my faves, the NetBeans Collaboration Feature) to Snipt to allow for a quick-pull or quick-push for snippets. Another alternative, for the Eclipse fans, would be to selectively or globally expose their snippet whiteboard areas. And, for even more fun, push/pull Hg stored blocks or snippets! (… well, yeah, maybe even SVN or CVS stored stuff, too…)
I suspect that, for FOSS projects, Snipt will be (if it hasn’t already been) quite useful. As a means to address educational needs, it’s useful– unless somebody is writing drek.
On the topic of educational stuff… would you know if CS/IT students are using Snipt to get answers to assignments that they should be working out on their own? It’d be out-of-scope for you to have to police access to Snipt, but I’m curious whether that usage scenario has started to play out yet…
(If you haven’t guessed yet, I love to discover the various unexpected ways that things are being used…)
{ 1 trackback }