So if Palm was going to choose an OS, you'd have thought that they'd have picked something that allowed them to differentiate and to control their own destiny. An OS like embedded Linux, or Symbian perhaps. But no, they had to move to the only OS I suspect I'm going to have hard time syncing my Mac with; the same one used by every other freaking PDA phone out there (all of which suck).
And, now they add insult to injury by emphasizing the Blackberry software, and if -- in the process -- they make it "hard" for us IMAP client users to use what we want, again I'll be stymied.
So I guess I hope Apple actually gets into the business for real and not just partner with Moto. If they do, maybe they'll get real-time audio, WiFi, VoIp, and various bits of software right....:-)
Please forgive the self-promotion, but my self-promotion arises from a serious attempt to address this specific problem. Go look at the team work management software called "Chirp" at http://www.plumcanary.com/. (Product info here).
I agree with what many others said: getting a handle on this is more about personal discipline than software. But software can help develop good discipline.
I wrestled with this problem for 15 years. I started as a developer, became a product manager, then a VP, then a CEO. I finally latched onto some techniques that worked, but there wasn't any software to support them. NOTHING I found did what I needed:
Keep track of who is working on what;
Replicate this info to everybody on the project team;
Have the person doing the work keep a status up to date and then replicate the status updates;
Work both online and offline (so I could do stuff on the plane; web-based was non-starter);
Didn't make me wrestle with with Gannt charts. Forgive me, but MS Project misses the point when it comes to ongoing management of a team. It may work when you're planning a large, autonomous project; for most people, it doesn't map well to what is needed to simply manage a team doing lots of stuff.
Get a quick "How's it going" view in a table that I could slice and dice based on various selectors;
And isn't email. Email sucks as a way to manage a team. Period. (Don't get me started.)
So I started a company to build software to do this. I've looked seriously at the issues. It isn't perfect yet; but it's getting pretty damn good (IMHO). Chirp is the result. It's now in Release 2. Go give it a 30-day trial. You won't hurt my feelings if it doesn't meet your needs.
Something less invasive. Skype's peer-to-peer discovery techniques used at startup "learns" too much about my network "inside" my firewall by doing all kinds of broadcasting, exploring, poking, etc. I don't like it when some other, random company's software starts dissecting the organization of my internal network. I don't trust what they will, or won't do with that info, particularly since it is in the hands of a company who has a demonstrated willingness to do things the rest of the world may not be happy with but that it thinks are "good."
Something that the open source community can expand on in the way the Skype APIs are doing, but not do it in only the ways Skype -- in it's infinite wisdom -- decide are things that are useful / ok / interesting. This is the very beauty of open source -- lemme do what I want.
Play well with others. There are tons of SIP-based products and services starting to enter the market. (See the lists at www.sipforum.org and www.sipcenter.org, etc.) Skype is attracting some providers for SkypeOff, but I'd rather take advantage of the SIP industry's last 5 years of work to make a broad array of products (VXML engines, conference control interfaces, media servers, IP PBXs, etc.)
Oh, and to the point that Skype's firewall piercing is unique or unacceptable -- it isn't. See an analysis of Skype signaling done at Columbia University. Skype appears to use a variant of the STUN/ICE technique currently being worked through in the IETF for use with SIP, too. What isn't acceptable in the corporate environment is the local LAN probing / discovery that Skype does at startup!!!
So I want something that plays well with me, and others.
Contrary to the assumption in this specific post, this is not a case of spider/package/sell. Pingtel itself wrote 100% of this software in the 6 years of its venture-backed history prior to releasing it under an open source license. This was previously closed-source software from a company that decided to shake up the VoIP business by shifting from a closed-source model to an open-source model.
So Pingtel is not merely selling something they didn't work hard to create. They made the original corpus of code, though the growing contributions of others will clearly improve it.
And even after these contributions grow in proportion to Pingtel's original source, there's still benefit in providing the same service RedHat does: decide what is ready for "prime time enterprise deployment" and what isn't, and package a release accordingly.
Sorry, but I'll be honest here. I'm the founder of Pingtel, and this bit of technology is my baby. I need to disabuse the notion that SIPx = windows.
You have it *exactly* backwards. Please allow me to explain.
First, context/history. I'm a Unix dude at the DNA level. I was writing C code to build curses applications on 68000-based Unix Version 7 boxes when most of you were still sucking baby bottles. (Curses? Mr. Peabody-- you set the wayback machine too far back!) My Pingtel cofounder and I built the worlds biggest Unix-based massively-parallel processors at BBN in 1987-1992, he being the Unix OS software engineering team lead. We were contributing to IETF standards back before most people knew what the IETF is. I use a mac now, but it's Unix with a nice face....;-)
When we approached the design of SIPx (and the phone, and all the other products we built), we designed them in "the Unix way." SIPx is architected as a set of separate applications that each do their job well, and then work with other to build a system. So there are:
SIP proxies
SIP registrars
SIP "endpoints" to do voicemail, auto attendant, soft phones,...
Database engines to manage config
Web applications (JBoss) to provide a user-friendly UI
The bits can be used together to build an IP PBX. OR, you can use the case core components in different combinations to build other stuff, like call routers, media application servers, etc. Heaven knows we built a ton of different things and threw them away without productizing them while I ran Pingtel.
And all of it leverages Unix and IP network stuf to the hilt. We opted for DNS records for load balancing, blah blah blah.
In contrast, my last look at Asterisk code (admittedly about 8 months ago) showed the code was architected *exactly* the opposite way. It appeared to be a more monolithic, but pluggable architecture. Just as Pingtel's code base shows its roots in being a spectacular user agent, Asterisk showed its roots in being a well-developed extension to the Digium gateway card. (Both have pros/cons). Mark, I'm sure you'll read this, so please forgive me for saying this - I promise to try to be as professional and fair as possible in industry events, contacts, etc. But IMHO, when I read Asterisk code, I had deja vu of code supplied by companies from whom I've bought hardware in my 25 year tech career, e.g. ethernet chips/drivers, DSP chips/libraries, etc. Good, useful stuff, but not the same as something architected from top down.
But when taken as a whole, my read of the Asterisk code was that it was more like a PC-based PBX software application that has grown. A little like Windows still shows its roots in DOS (not *really* multi-user, etc.)
In contrast, the sip foundry (Pingtel's old) code base is really a set of modular components that can be strung together to make a variety of things. Kind of like Unix shell applications with pipes, or daemons working with applications, etc. Kind of like Unix.
So "SIPx = Windows" is exactly backwards, and (IMHO, though you are free to throw rocks at my analysis), "Asterisk != Linux/Unix."
I'm clearly biased. I stopped writing C code in 1994, and I haven't written C++ code in 8 years (though I still dabble with Java, you can challenge me to anything you want in CSS). But I'm competent, confident in my judgement, and don't want SIPx to take a rap it doesn't deserve. It has huge legs, several tens of millions of $ of VC-backed engineering investment, and as an open source project will -- I hope -- get the community backing it deserves.
-jb
PS -- I'm not going to throw too many stones at IAX because I'm not as conversant as I should be to defend myself. But don't you want to take advantage of the dozens of other SIP-based products and services that are in the market? IAX is nice, but a distraction. SIP has firewall stuff figured out, too; we just need to get it into the SIP Foundry code.
Slashdot Mirror
So if Palm was going to choose an OS, you'd have thought that they'd have picked something that allowed them to differentiate and to control their own destiny. An OS like embedded Linux, or Symbian perhaps. But no, they had to move to the only OS I suspect I'm going to have hard time syncing my Mac with; the same one used by every other freaking PDA phone out there (all of which suck).
:-)
And, now they add insult to injury by emphasizing the Blackberry software, and if -- in the process -- they make it "hard" for us IMAP client users to use what we want, again I'll be stymied.
So I guess I hope Apple actually gets into the business for real and not just partner with Moto. If they do, maybe they'll get real-time audio, WiFi, VoIp, and various bits of software right....
I agree with what many others said: getting a handle on this is more about personal discipline than software. But software can help develop good discipline.
I wrestled with this problem for 15 years. I started as a developer, became a product manager, then a VP, then a CEO. I finally latched onto some techniques that worked, but there wasn't any software to support them. NOTHING I found did what I needed:
- Keep track of who is working on what;
- Replicate this info to everybody on the project team;
- Have the person doing the work keep a status up to date and then replicate the status updates;
- Work both online and offline (so I could do stuff on the plane; web-based was non-starter);
- Didn't make me wrestle with with Gannt charts. Forgive me, but MS Project misses the point when it comes to ongoing management of a team. It may work when you're planning a large, autonomous project; for most people, it doesn't map well to what is needed to simply manage a team doing lots of stuff.
- Get a quick "How's it going" view in a table that I could slice and dice based on various selectors;
- And isn't email. Email sucks as a way to manage a team. Period. (Don't get me started.)
So I started a company to build software to do this. I've looked seriously at the issues. It isn't perfect yet; but it's getting pretty damn good (IMHO). Chirp is the result. It's now in Release 2. Go give it a 30-day trial. You won't hurt my feelings if it doesn't meet your needs.Oh, and to the point that Skype's firewall piercing is unique or unacceptable -- it isn't. See an analysis of Skype signaling done at Columbia University. Skype appears to use a variant of the STUN/ICE technique currently being worked through in the IETF for use with SIP, too. What isn't acceptable in the corporate environment is the local LAN probing / discovery that Skype does at startup!!!
So I want something that plays well with me, and others.
So Pingtel is not merely selling something they didn't work hard to create. They made the original corpus of code, though the growing contributions of others will clearly improve it.
And even after these contributions grow in proportion to Pingtel's original source, there's still benefit in providing the same service RedHat does: decide what is ready for "prime time enterprise deployment" and what isn't, and package a release accordingly.
You have it *exactly* backwards. Please allow me to explain.
First, context/history. I'm a Unix dude at the DNA level. I was writing C code to build curses applications on 68000-based Unix Version 7 boxes when most of you were still sucking baby bottles. (Curses? Mr. Peabody-- you set the wayback machine too far back!) My Pingtel cofounder and I built the worlds biggest Unix-based massively-parallel processors at BBN in 1987-1992, he being the Unix OS software engineering team lead. We were contributing to IETF standards back before most people knew what the IETF is. I use a mac now, but it's Unix with a nice face.... ;-)
When we approached the design of SIPx (and the phone, and all the other products we built), we designed them in "the Unix way." SIPx is architected as a set of separate applications that each do their job well, and then work with other to build a system. So there are:
The bits can be used together to build an IP PBX. OR, you can use the case core components in different combinations to build other stuff, like call routers, media application servers, etc. Heaven knows we built a ton of different things and threw them away without productizing them while I ran Pingtel.
And all of it leverages Unix and IP network stuf to the hilt. We opted for DNS records for load balancing, blah blah blah.
In contrast, my last look at Asterisk code (admittedly about 8 months ago) showed the code was architected *exactly* the opposite way. It appeared to be a more monolithic, but pluggable architecture. Just as Pingtel's code base shows its roots in being a spectacular user agent, Asterisk showed its roots in being a well-developed extension to the Digium gateway card. (Both have pros/cons). Mark, I'm sure you'll read this, so please forgive me for saying this - I promise to try to be as professional and fair as possible in industry events, contacts, etc. But IMHO, when I read Asterisk code, I had deja vu of code supplied by companies from whom I've bought hardware in my 25 year tech career, e.g. ethernet chips/drivers, DSP chips/libraries, etc. Good, useful stuff, but not the same as something architected from top down.
But when taken as a whole, my read of the Asterisk code was that it was more like a PC-based PBX software application that has grown. A little like Windows still shows its roots in DOS (not *really* multi-user, etc.)
In contrast, the sip foundry (Pingtel's old) code base is really a set of modular components that can be strung together to make a variety of things. Kind of like Unix shell applications with pipes, or daemons working with applications, etc. Kind of like Unix.
So "SIPx = Windows" is exactly backwards, and (IMHO, though you are free to throw rocks at my analysis), "Asterisk != Linux/Unix."
I'm clearly biased. I stopped writing C code in 1994, and I haven't written C++ code in 8 years (though I still dabble with Java, you can challenge me to anything you want in CSS). But I'm competent, confident in my judgement, and don't want SIPx to take a rap it doesn't deserve. It has huge legs, several tens of millions of $ of VC-backed engineering investment, and as an open source project will -- I hope -- get the community backing it deserves.
-jb
PS -- I'm not going to throw too many stones at IAX because I'm not as conversant as I should be to defend myself. But don't you want to take advantage of the dozens of other SIP-based products and services that are in the market? IAX is nice, but a distraction. SIP has firewall stuff figured out, too; we just need to get it into the SIP Foundry code.