[Pythonmac-SIG] Mac User Python newbies

Bob Ippolito bob at redivi.com
Wed Feb 9 08:37:56 CET 2005


On Feb 9, 2005, at 1:50 AM, Roger Binns wrote:

>> Yeah, exactly.  There's not even twice as many Windows projects as 
>> Mac OS X projects, and far more Linux projects that Windows projects.
>
> Note that it didn't include Windows 98 or the generic Win32 category
> (trying to categorise a project on SourceForge is a real pain!)

Even still, given how wrong it is for NetBSD, I find it hard to assign 
any weight at all to what sourceforge's numbers are.

>>> It doesn't matter how cheap and fast it is for 5% of the market.
>> Sure it does, if you release OS X first it can fund Windows 
>> development and testing.  Worked fine for us.
>
> A counterpoint (see 1/3 of the way in)
>
>  http://www.joelonsoftware.com/articles/fog0000000051.html
>
> wxPython certainly goes a decent amount of the way towards his 
> underlying
> message.  And MacOS is on a nice uptick since that was written.  This
> is all just proof of the network effect and what it takes to overcome
> it (perseverence).

That article is four and a half years old, and it doesn't account for a 
lot of things.  In our case, it was roughly 10x easier to hit the Mac 
platform first and it made a lot more sense given the startup capital 
and time we wanted to spend on launching the product.  It's also a lot 
easier to get press for Mac software, for whatever reason, where we'd 
have to spend even more money marketing the Windows version to get it 
out there.  The Mac version paid for the Windows version, threw free 
press in our direction, and got us a publishing deal.  In hindsight, 
I'd have done it the same way.

I can't really say whether we have more Windows users or Mac users now, 
because our software doesn't phone home and both versions ship 
together.  There is a disproportionate amount of support requests on 
the Windows side, but that's because it more or less Just Works on the 
Mac, where there seems to be some weirdness on some obscure Windows 
configurations that we can't reproduce (unfortunately we're at the 
mercy of some other software and hardware for this product).

> Some other food for thought:
>
>   http://www.joelonsoftware.com/articles/fog0000000017.html
>   http://www.joelonsoftware.com/articles/Platforms.html
>   http://www.joelonsoftware.com/articles/fog0000000020.html
>   http://www.joelonsoftware.com/articles/APIWar.html
>   http://www.joelonsoftware.com/articles/fog0000000052.html
>
> It is all our interest to make Mac a better platform and to make
> it very easy to write code that just works on Mac and elsewhere.
> One of the things I am proud of in BitPim is the almost equal(*)
> seamless support of all platforms.  As a developer, operating
> systems and APIs matter to me.  But as a user, they are irrelevant.
> You want programs to just work on whatever is connected to your mouse,
> keyboard and screen.
>
> (*) The Mac is the least equal due to wxWidgets and me not being
> able to get a reasonably priced Mac.  The Mac mini fixed the latter
> and OSAF paid for some of the former.

The user also doesn't care if the UI code isn't shared between all 
platforms as long as they're maintained.  The Tkinter GUI and the 
PyObjC GUI share a bunch of code (as much as is reasonable).  The 
Tkinter GUI actually has code in it to emulate a bunch of Mac-isms and 
it reads resources directly out of its sibling Mac OS X bundle 
(metadata, localization, and the application's data).  I'd have used 
wx, but Tkinter was easier for this and wasn't as big.

>> I think we're probably going to have real GNUStep support for PyObjC 
>> sometime in the next few months.. though I'm not sure whether the 
>> NeXT roots count as Mac or not.
>
> I did have it in my draft email, but couldn't find suitable Python
> bindings.  I'd be happy to count it as Mac.  Which incidentally is
> one of the annoying things come fresh to Mac as a developer.  There
> is all this legacy NS crap!  It is *nowhere* near as bad as the
> legacy in Windows though, or even the Linuxisms :-)

NS is just a namespace.. Not much of it *feels* legacy :)  At least 
they're consistent.

-bob



More information about the Pythonmac-SIG mailing list