SitePen has been building an amazing team and today we're bringing a little of that team to a lot more of the Dojo world.
As part of the relaunch of sitepen.com, we've unveiled our new support offerings (the available packages are here). For some time now SitePen has been offering consulting to firms using Dojo, and we've recognized that many of our clients aren't prepared to engage us for a consulting engagement but need more than an intensive training session for their teams. In this middle area lies the need for a support product which can help capable teams get un-stuck quickly when the going gets tough. Other customers have expressed a strong desire for professional support due to their enterprise's nascent experience with Open Source, and for them we've built "lightweight consulting" into the Enterprise plan to help get architectural issues addressed in addition to handling pressing fixes.
SitePen is adding this support product to our already successful application development and Dojo/DWR training businesses. Since we're also building apps, we know how important it is to have the right person an email or phone call away. Support is a logical progression for us as a company and for Dojo as a project, and we're committed to doing it right. Everyone we've assembled to provide support to our clients are committers on the projects we support (sharp tacks, all) and as we described recently at DDD the plan for SitePen's support business is designed to help us improve the toolkit at every opportunity. Right there on the page describing the packages you can see our commitment to keeping Dojo a healthy Open Source project:
When you find an issue with Dojo, DWR, or Cometd, we...provide you with emergency bug fixes. We also commit these patches back to the relevant open source project as appropriate.
SitePen has also recently been working to help ensure that Dojo's API documentation tool is top-notch and that the introductory material for getting started with Dojo are solid, all of which we'll be releasing in the coming weeks alongside the release of Dojo 1.1. In all of the support team discussions, it's been clear to me that everyone involved gets it: not only are we here to support our customers, we're here to make Dojo and DWR better for everyone in the process. It's the kind of positive feedback loop that only happens when you have the right people on the bus and when the whole business understands the real value of Open Source both to customers and to the community.
Speaking of making things better, we're convinced that the last thing you need when working with our support team is a headache. The support UI has to be as easy-to-use as it is good looking, so we’ve built a custom support interface that lets customer submit tickets, check the progress of ongoing ones, and use completed tickets for reference. Check it out:
I just landed in Vegas where i'll be for the next several days at Mix '08. I'm looking forward to hearing more about what the IE team has in store for IE 8. I've got a whole stack of questions and they've promised a frank discussion without any pre-conditions or NDAs. This oughtta be good. If nothing else, it will tell us how far retracted the IE Cone Of Silence (TM) is. I've got hope, but I've been teased before and despite an impending Beta, there's precious little to go on about what IE 8 really will and won't be (or even when).
I'm not a gambler, and generally don't like Vegas, which makes me all the more excited to be going to SxSW directly from MIX. I haven't been in a couple of years, but Dylan has been keeping the annual Dojo Salt Lick field trip alive, and I'm excited to be able to be able to join the rest of my (mostly Silicon Valley) compatriots in stumbling around Austin under the influence of Shiner and BBQ. If you're also going to be in Austin (at SxSW or not) and want to join us in our trip to BBQ Mecca, just RSVP and let us know how many you intend to bring and whether or not you can drive others.
Oh, and there will be an auspicious panel wherein authors of successful JavaScript libraries will all thank John for doing the work of proposing a panel and therefore ensuring that we all have an excuse to come to Austin to drink Shiner and eat BBQ. The last time I went to SxSW I hosted a panel with some of the smartest people I know and it went over like a lead brick, convincing me once and for all that SxSW is the Jerry Springer Show of technical conferences and that the point of panel discussions there is to stir shit up. It doesn't even matter what it is...everyone else there is nursing the same mild, Shiner-induced hang-over and if they really cared about technical content...well, they would have gone to ETech.
If you're going to either MIX or SxSW, let me know! Conferences are always more fun when you know the Hallway Track is going to rock.
Update: there's much to say about MIX now that it's over and IE 8 is in our hands, but apparently we've communicated about the Salt Lick thing very poorly. While we'd love it if you'd RSVP to rsvp at dojotoolkit dot org if you're joining us, what you really need to know is when and where. Namely:
- When?
- 8pm, Sunday March 9th
- Where?
- The Salt Lick
18001 FM 1826
Driftwood, Texas 78619
Remember, it's BYOB and if you RSVP we can help coordinate rides and such. Looking forward to seeing you there!
The Dojo community is going at a clip that I can barely follow these days. Notably:
- Dojo Campus: Nikolai Onken and Peter Higgins have been cranking out tutorials, screencasts, and "dojo cookies" to explain and entertain
- Matthew Russell, author of the forthcoming O'Reilly Dojo book is blogging up a storm over at OnLamp
- Robert Coup keeps turning up practical bits about real-world Dojo use and integration
That and a whole lot more comes over the transom via Planet Dojo. Big props to Peter for keeping on top of things an adding new feeds to the Planet as they emerge.
Update: One more for the pile! Tony Issakov's Dojo Findings blog is worth a read/add, particularly as he's digging into Dojo+Jaxer
I've written before about the importance of clean licensing to an Open Source project, but one of the things I didn't cleanly outline is the case for clean licensing from the point of users. Understanding why clean licensing is valuable to users helps to further cement why it's valuable to projects, and why well-run projects have such a hard job when it comes to building the inclusive, "lets try anything" spirit that it takes to succeed while watching out for the interests of their users down the road.
Put bluntly, it boils down to risk. What are the odds that someone contributing to the project I'm using will decide later that they've changed their mind about giving away their hard work for free, particularly if the project becomes super-successful? And what is the project doing to mitigate that risk?
It's worth remembering that the projects themselves don't often have much to fear when it comes to "unclean" contributions and are entirely unlikely to change their basic terms of distribution (unless all the code is copyright one person or legal entity), which leads many projects to take an approach of "looks good to me..." when it comes to accepting patches. Most OSS projects don't have any money, and suing an OSS project is a political nightmare. All of this means that the risk of choosing poorly is often externalized by projects. That is to say, they make it users' problem; you got the code for free and now you're whining? (but of course you are...you're still "paying" for the code in other ways) Lastly, if the project us under the GPL, there isn't any real risk so long as the project has a public record of where patches came from (i.e., public source control that anyone can inspect).
So already we've got some big warning signs that we can look for to determine if a project is looking out for my best interests as a user:
- Is the source control system open? Is the entire version history of the project represented by what's in source control?
- Are you using it under the terms of a GPL-ish license?
If so:
- Can you view the history of the project's source control?
If not, you still need to care about public source control; but also:
- Are patches attributed in checkin notices?
- Are there other policies in place to ensure that patches are "clean"?
- Is the entire code-based copyright a single person or company? If so:
- How is the community "bought in" and what kind of say do they have in licensing policy?
- Is that person/company insisting that patent rights also be transfered to them along with copyright?
At this point anyone familiar with even the basics of the licensing of OSS JavaScript toolkits will note with wry amusement that I'm describing a set of criteria that cast Dojo Foundation projects in a favorable light...and of course I am; we set up the Foundation's licensing policies to explicitly avoid the kinds of pitfalls that large users of OSS already know to avoid. This post is simply about helping everyone else understand that logic. That your tools of choice may not compare favorably isn't for a lack of effort on our part. As I've said over and over, we welcome any deserving project under the umbrella of the Dojo Foundation. Enough about that, though. Back to the nuts and bolts.
As a user of Open Source code, my biggest concern is always that the code does what I want it to. There are lots of creative ways to isolate poorly licensed projects when building an app, but I'd much rather not expend the effort if I can avoid it. Some licenses (in some situations) may even impact my business model, so very close behind "is it good?" in my mind is always "how's the license?". When given a set of roughly equivalent options, big OSS users often flip those concerns. For them (and possibly for you), the hassle, risk, and expense of funky licensing absolutely outweighs functionality. Some are so large in-fact that using or backing an OSS solution is simply a market expedient and not a necessity in any way. But you and I aren't that big (probably), and besides, we like our tools just fine.
And this really cuts to the crux of the issue: despite not having paid anything for the software, choosing a particular tool means investing in it. Learning the APIs alone is probably a significant investment, and porting to some other solution will require time and effort. OSS means you're not putting up cash at the get-go, but certainly as time goes on there is a very real investment in the Open Source infrastructure that we build products and projects with. How "solid" is that investment going to be? Obviously, we can't know what's going to happen in the future, but can certainly steer clear of potential problems once you know how to look for them.
Which leads to the last point, and one which I've heard parroted by other OSS project leads who haven't been as careful: are people seriously going to get sued? I mean, is this ever really going to matter?
Admittedly, Open Source licensing lawsuits are rare, and most small organizations never see them. Instead, what they see are opportunists and shake-down artists like SCO knocking on their door years later for "licensing fees" about some IP they may never know they've swallowed. The SCO suit was a weak case in part because SCO had itself distributed Linux and the kernel was GPL'd. Even the lamest and dumbest of trolls must surely have learned something from SCO's public humiliation, no?
My only answer for this is that many of Dojo's users get sued only because they have money and the sun is shining. That's not going to change because they chose Dojo or don't, but there is serious opportunity to for components like Dojo to put them in a bad situation were we not as careful as we have been about the licenses of all the components of the toolkit including images and CSS; not just code. I cringe every time I see an Open Source rich-text editing control which uses icons which could easily be confused with those from a certain (litigious and Open Source fearing) Washington-based software distributor. Those projects may never see so much as a C&D, but their users may be in for hurt. Now imagine if that were an entire UI theme and not just a couple of icons? Oof. If the projects which are saying they aren't hearing concerns from their users reflect on it a bit they may realize it's just as likely as not a question of timing and self-selection. The big OSS-savvy organizations have passed them over. Why deal with the headache?
The pedigree of the inputs into a project determines the legal risks associated with its use down the pike. Since we can't eliminate risk, only mitigate it, it pays for all of us to ask questions about the licenses of the projects our products and projects make use of now — while it's still cheap to do so. Hopefully by doing so, we'll not only push the good code to the top but also build a licensing foundation that we can work from without ambiguity or risk for decades to come.
I just spent 20 minutes in IRC with Wolfram staring down one of those situations where you keep swearing under your breath "println isn't broken....println isn't broken....println is NOT broken".
Catch this fun gem from FF3b2:
>>> typeof []
"object"
>>> var a = [];
>>> var b = new Array();
>>> a.constructor == b.constructor
false
>>> c = [];
[]
>>> c.constructor == a.constructor
true
>>> d = new Array();
[]
>>> b.constructor == d.constructor;
true
>>> b.constructor == a.constructor;
false
WTF?
Older Posts
Newer Posts
