Don't Ask, Don't Tell - and OpenNTF
There's been a bit of a brouhaha (yeah, you got me, I've been looking for excuses to use that word...) about some of the changes to OpenNTF recently. I was about to link to them, but then I realized - you don't need links, just look for the heaviest traffic on PlanetLotus. :D
In case you've been living in a cave, IBM is officially involved in OpenNTF now, for the first time ever, and we're starting to see the impact of that. Among other things (like heavy, paid involvement from Messrs Castledine and Heidloff), there is a new "catalog" of officially sanctioned projects. In order to become approved, there are some new requirements. This is where the complaints start to show up, of course. We all know that nobody likes change, so a certain amount of grief is inevitable. The devil is in the details, though, as they say. So, the controversies are (drumroll, please):
1. For one thing, the only approved projects at this point come from IBM themselves. That makes sense, of course - they had to have some projects to use as guinea pigs and it makes sense to choose their own. The IBM projects are also the only ones that meet the criteria at this point, because - obviously - none of the major project owners knew the details about those requirements. That's unavoidable. As long as non-IBM projects start to be approved at some point, I don't see an issue here.
2. Another item, a bit more contentious, is the licensing requirements. The approved catalog requires the Apache license (at this point, though there is a board of reputable people involved [plus Nathan - :P] and things could change if the board decides they should). The Apache license basically says that anybody can take your code, or part of it, and sell it (or give it away) themselves. So, the code is truly OPEN at that point. Some current OpenNTF participants really prefer a GPL model, where use of their code in any other application requires THAT application to be released under the GPL. This is a tricky issue, because a lot of developers would be quite unhappy if somebody else took their code and made a fortune off it. On the other hand, many corporations will never implement a GPL'd application because of the possibility that they'd be required to give away all of the internal code. It's not a simple question, and it's been a big bone of contention ever since OpenNTF was launched. So while the apache license requirement raises some questions and will require some good communication and education within the community, it's a net positive to have this issue addressed. Finally.
2 (a). A corollary to this, though, is that only Apache licensed code (APL, from now on) will be listed in the new "catalog" - actually, only APL code that's been approved for quality AND has item #3 below under control - the existing projects won't be moved into the catalog until they meet the criteria. I don't agree with that. News flash: we're computer geeks. I'm pretty sure we can manage to come up with a way to have one catalog display both the fully IBM-ified, APLed, verified applications as well as the existing projects that drove the entire OpenNTF community and made it worthwhile for IBM to get involved. The way it's being handled now, there are two classes of apps, and as a certified flaming liberal (TM), I gotta tell ya - separate but equal isn't. Equal, that is. And for projects like BlogSphere or OpenLog to be considered second class citizens is more than a bit obnoxious.
Here's an idea. Use a freakin' flag field (or more than one) to indicate the various levels of approval a project has reached. Some may be APLed, but not pass muster because of a lack of documentation. Some might have truly outstanding documentation (OpenLog, I'm lookin' at you) but not be APLed. What's wrong with listing them all in the same place, sortable and searchable in multiple ways? From a UI perspective, that's not rocket science. And in terms of respect owed to the people who put so much time and effort into their projects, it should be a no-brainer.
3. One other requirement says that in order to submit code to an approved project, all developers have to send an official approval from their employer, stating that they are allowed to share this code. This one is very controversial, too. And this is something I will have trouble with, personally. See, Acme Inc, aka my employer, would never agree to that in a million years. There's no imaginable future in which the legal and security overlords will publicly assert anything on any subject at all that Acme Inc doesn't absolutely require in order to run its business. I don't know how typical that is, and certainly we are on the extreme end of a number of policies related to IT, legal, and security issues. But as currently written, that requirement bans me from contributing anything to any new (or approved, sanctioned, etc) OpenNTF projects. Now, since I've contributed to only one so far (and that, extremely minimally), that's not a huge loss. There are a couple of things I was hoping to contribute - new projects - but those will now obviously not happen. And there is certainly a very good reason for this requirement. Some companies have contracts with their developers that claim ownership of anything that developer creates, regardless of whether the work is done at work or during business hours. In other words, if you have signed that sort of contract, you are not allowed to run a consulting shop in your spare time and you're definitely not supposed to contribute to open source projects. So if you've signed said contract, you create an open source project, and Company X uses said project then Company X can be liable for a civil suit. Not cool.
So, while we're waiting here between paragraphs, why does the title of this post include the "Don't Ask, Don't Tell" phrase (aka DADT) most commonly associated with US military policy designed to allow homophobes to pretend they're ostriches ("nope, no gays here, I don't see 'em so they must not be here...")?
Funny thing. DADT is similar to the deal I have with Acme, Inc about my role outside of the company. I speak at conferences, write articles, and blog about all kinds of stuff. I don't say anything about Acme, and Acme doesn't ask me what I'm doing. That's the deal. I can't mention the company name in any way (not even on my Lotusphere badge). In exchange for that, they let me do what I enjoy doing. I did NOT sign a contract that says Acme owns my intellectual property (and I never would, though I'm assured by my brother the hotshot lawyer that they're unenforceable in the real world - but remember, IANAL nor do I play one on TV). But they won't attest to that publicly because there's no benefit to them in doing so - certainly not enough benefit to outweigh their legal/security concerns.
And in this one, rare case, I know I'm not unusual. A lot of IT geeks have second careers outside of the day job, many of them have not signed intellectual property clauses, and most of those people will not be able to get their companies to go public about that. There's a bit of a contradiction here, ironically. The companies most likely to require intellectual property clauses are IT services/consulting companies. These companies make their money on the intellectual property, while the rest of us make our money selling widgets. Those are also the companies most likely to be willing to allow their people to open source a project, because it's good PR for them to be recognized as authorities in the various technologies. So the OpenNTF folks have created a rule that allows those folks to participate, which is great. But in doing so, they're preventing another set of people from participating, and that's not great. It may be necessary, but it's not a good thing.
It may be worthwhile to explore opportunities to change that. I don't *personally* see why project owners and contributors can't simply be identified (by their profile) as either having official corporate approval or not. That information could then drive policies around who is allowed to work on what project. It might be that the DADT crowd could only work on projects with each other. But if those projects are of high quality, they should be in the catalog along with the others, flagged to indicate that they cannot be used by companies concerned about the legal ramifications. People could use them personally, people could learn from them, and some companies could use them as they are - which is exactly what happens now. It's not as good a result as the one obtained by projects that meet all of the new requirements - don't get me wrong, I'm under no false illusion - the apps that meet the new requirements could conceivably be much more widely adopted in the major Notes customer sites. And that would be a Very Good Thing. But in my never particularly humble opinion, banning a Pretty Good Thing shouldn't be a pre-req to achieving a Very Good Thing.
|
Permalink
| Comments (11)
| 
- 
