Good job. I have an idea that might benefit Compose now. Research projects I've read on in IBM said that IBM allowed the internal use of any of its software tools for free. They have a lot of really good ones that you'd normally pay large sums for. I'm not sure if this policy (a) still exists or (b) applies to companies they acquire. However, if I was Compose, I would ask about it because IBM's tools & tech could greatly aid Compose in developing their stuff faster, more robustly, etc.
Plus, I'm sure other startups might want to know whether this benefit exists or not. Might even factor into a decision of whether a company wants to be acquired by IBM vs another company. A 100+ free (or cheap) software products would really really sweeten the deal to me if I was to continue working at the company post-acquisition. Especially those delightful, bug-hunting and productivity-boosting products. :)
Anyone on the inside know the answers to any of this?
Having worked at IBM briefly this is only partially true.
The way I understood it, IBM has a system called "blue dollars" or "blue bucks" I forget which one. Basically, groups within IBM are given an allotment of credits they can spend to "buy" other IBM products.
Ex IBM'er here and I recall it as Blue Dollars. I was in one of the UK labs so 'bucks' isn't a term we really use.
When it comes to software, you pretty much can use any IBM software you want (or are told to). A lot of the Rational products were heavily pushed for teams to use, although I think you had to justify why you use it. This caused some contention, as I worked in automated UI testing and the capabilities of IBM products vs open source alternatives varied quite widely. It was always fun justifying your decision to management when the IBM product didn't match your needs.
But when there is a service cost things are different. I got pulled into my manager's office being showed my bandwidth and storage cost of my Lotus Notes emails and was heavily encouraged to download my emails locally as the department was charged. I think there were similar considerations when it came to using backup software into their TSM - I don't remember exactly but have a feeling you needed management approval to use it.
Then you have the consideration of building one product from another. For example, I worked on WebSphere Application Server which was the app server of many other IBM products. There you have the consideration of which departments earn the revenue when a core product is shared.
Appreciate it. Now I just gotta figure out if this applies to companies they acquire and are integrating into their offerings. That's the original comment I posted: Compose should use their tech where it's good and they get it free/cheap.
This is my understanding as well - you don't just get all the IBM software you want, but there are ways to internally acquire what you need on funded projects (or similarly, I would assume, acquisitions).
It's worth noting that more and more of IBM's software/platforms are cloud-based and even publicly available (e.g. Bluemix) so I imagine the landscape for this type of software acquisition is changing even internally.
You hit the nail on the head. There is some kind of free policy but the overall one is called "blue dollars." This just means what they charge internally for stuff and has less value than the "green dollars." I found this illustration from 2003:
I doubt they'll give up $780+ million any time soon. However, my proposal in another comment to at least temporarily bill software at cost or for free might benefit them considerably in both green and blue dollars.
All really strange to a guy like me whose companies only dealt with green money and just used cost for internal expenses. :)
Seriously? IBM has a whole portfolio of technology with plenty being very competitive. It's one part of how they're the largest tech company. Getting their software free or hardware at cost internally would be a strong enabler for about anything.
This would be a nice start for a division or project: Rational w/ all analysis & productivity addons; the management software; cloud services (i.e. backups); security services/software (basic); an IBM i (comes with DB2) for critical stuff. Add in some servers and storage appliances [from IBM] where needed as growth occurs. Also remember that that Microsoft used to run their whole business on one AS/400 until they were called out and replaced it with 20+ Windows servers to match performance/reliability. Funny stuff.
They have all kinds of good tech. A permissive policy on its use, even if for limited time, could greatly aid internal projects and growth of companies they acquire. If I was them, I'd throw my weight into everything on the software side given it would be as easy as an order, a license, and a download. ;)
There's a lot of examples. Have a look at Bluemix.net, Jazz.net, Bluemix Devops Services (https://hub.jazz.net/) and some of the DevOps tooling like Urbancode.
I actually have an awful lot of time for Rational Team Concert. The VCS is quite well tuned to include some of the notable benefits of DVCSs, while keeping things a bit simpler to work with. Work items are really nicely integrated too.
Clearcase was a good idea in 2001, when the alternative was CVS. In 2015, I am wholeheartedly unconvinced it offers anything over git. (And I'm not a devoted booster of git.)
(I was nominally responsible for a Clearcase setup at Ericsson in 2001. I mentioned it in passing on the 2002 version of my CV, and no later version. I still get pings from those last few Clearcase shops, desperate to find someone willing to touch the thing.)
You may disagree, and perhaps Clearcase has substantially changed its model since then. What in detail do you like about Clearcase over (say) git?
Ah, I have no experience at all with ClearCase - I believe the VCS for RTC is a newer product with some conceptual overlap, but I'm given to understand it is typically substantially quicker and easier to get up and running with.
I'm conflicted on the VCS. It seems powerful, but the "bag of changesets" (instead of linear chain of changesets) model gives me issues when performing operations that I would commonly do on my git repos. In scripts I have written, I've encountered two changesets on the same stream occurring on the same second and accepted them individually in an incorrect order, which put the workspace in a screwy state.
(Also hitting the server for every little operation kills me. Even the command line tool just communicates to a java daemon to go hit the server, arrrrrgh.)
On reflection, I suspect a lot of it is less the actual VCS itself, and more the way it gets exposed in the UI. In contrast to git (where I'm 100% command line), I spend most of my time with RTC using the GUI, which is reasonably well directed towards the most common needs.
I think I also have a lot of positive thoughts about RTC because I remember how easy it felt to get started with it. With git it took me a little while to internalise how it worked, and I screwed up my repositories beyond my newbish ability to recover a few times. When comparing each to SVN, RTC provided me the improvements I cared about most (easy sharing, interim 'commits' prior to pushing to mainline), with very little learning overhead.
Combine that with really excellent work item/defect integration and I think it's a pretty compelling product. As you say, the constant communication with the server is a definite bummer. I think that comes out of the more corporate focus of an IBM product - for a centralised team sitting in the same building as the campus, a bit of server communication isn't such a big deal.
I'd be pretty salty about having to use the VCS if it wasn't so well integrated with the work items. Definite improvement over GitHub in that regard. (I've still entertained the thought of writing some sort of git translation layer, but I don't know either well enough to translate some of the crazier edge cases.)
It is an interesting point, but it really shouldn't matter what order you accept the change sets in as long as you accept them all, correct? Was it something specific to your project that caused there to be issues?
I'll try and reproduce the issue, but I think somehow the workspace knew it was in an inconsistent state, but wouldn't provide me the information to not put it in that state in the first place.
This was "fixed" in later versions of RTC with --accept-missing-changesets [0]
The last one I remember was Karger et al's paper on lessons they learned building Caernarvon smartcard OS for EAL7 security. They mentioned in the paper they chose the IBM tools for static analysis, etc because they were free for internal use. So, I'm trying to figure out (a) if that's IBM tools in general, (b) who it applies to, and (c) how much.
If tools were available, I'd certainly consider Rational's modeling, testing, and cross-platform features as worth due consideration. :)
There's risks. There's several approaches that come to mind: straight up free software; software and hardware at cost; one of these for a certain period to allow growth before charging for it.
The free software obviously isn't making the company money. However, most internal projects on a budget or startups in this era aren't going to choose IBM's tools. They're too expensive and not that popular. So, by not giving it away, they probably gain nothing in licensing. By giving it away, they gain nothing in licensing but might in the project's goal due to software's advantages.
For at cost, it might be sustainable. They continue to make most of their profit outside IBM. Inside IBM, they offer their products anywhere ranging from free to a considerable discount. The offer covers the cost of the product in terms of delivery, support, hardware, and so on. That money fuels development and/or cost-cutting on the offerings in general. Volume of IBM use alone might add several developers to any product. So, in this model, there's no losses past what they currently charge, the products get funds for development, and there are gains throughout organization via their benefits.
The final model is basically a trial period. The projects or acquired startups get to use their choice of products with discounts ranging from cheaper to at cost to free depending on budget. As budget or success grow, the discount gets lower. Over time, you have a division that's paying full price for the products or begins transitioning to others. You get the benefits of option 2 with some of what general market might pay.
Personally, I think Model 1 wouldn't hurt them except whatever they're charging for internal use. Model 2 seems to be the best with Model 3 having a chance of success. The reason I promote this is that IBM is sitting on a lot more potential than they're using, mostly due to culture. However, I think they could create significant, competitive advantages if all their projects and divisions could inexpensively use every key capability they've produced. Software productivity, security, infrastructure, and administration at the least.
Just wait bluemix has a track history of building a free tier of every service. Happened with sendgrid i.e. That was the policy at least
Bluemix has been weird to me. Got the hardest time to get founding and that annoyed the hell out of me. Couldn't even get space for the blue tilde group running (weird thing, maybe still on w3, maybe not)
Plus, I'm sure other startups might want to know whether this benefit exists or not. Might even factor into a decision of whether a company wants to be acquired by IBM vs another company. A 100+ free (or cheap) software products would really really sweeten the deal to me if I was to continue working at the company post-acquisition. Especially those delightful, bug-hunting and productivity-boosting products. :)
Anyone on the inside know the answers to any of this?