Code by Kevin

About
Code by Kevin, Programming, code, business, and other pursuits

Your Host
Kevin Walzer, software developer.



Home

Subscribe to RSS Feed
Get a syndicated feed of my weblog.

Archives
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006

Categories
Business
Software
General

Privacy Policy

Site design: Skeleton

 

Sun, 28 Jun 2015

Moving to open source, and cross-platform

I am undertaking some fairly significant changes to my apps.

First, I have decided to open-source all my code, while still charging for pre-built binaries. I'm a strong proponent of open source code, and this move has been in the back of my mind for years. I have nothing to hide in my code. Others may find the code, not just the apps, useful. So I am in the process of establishing open-source repositories of all my code at http://fossil.codebykevin.com, using the elegant, superb Fossil source code management tool developed by D. Richard Hipp, author of the hugely popular SQLite database. I am first making available various libraries and packages I use in all of my applications, and then will follow with the source code to the apps themselves.

Second, I will be taking my applications cross-platform whenever it makes sense to do so. I would like my apps to be as widely used as possible, and this means that I would like to get them on more platforms than just the Mac. In practical terms this means I will be re-working the applications' code a bit to account for differences in platforms (Windows and Unix/Linux have different keyboard shortcuts than the Mac, for instance). I expect these differences to be fairly minor. The larger challenge here will be to set up processes for building and deploying the applications on each platform. (I expect to provide pre-built packages for Windows and Mac, but because of the diversity of platforms and deployment systems in the Unix world, I will only provide source code there.)

Third, these changes will require not just some modification of my applications' source code to fit in reasonably on each platform, but a simplification of the code design. In practice, this means removing code that is not essential to the application's functionality, or re-implmenting code in a simpler, more cross-platform way. I have a lot of Mac-specific code in my applications that requires compilation and which provides features that does not exist on other platforms (the Mac's Services API, for instance); I also have complex platform-specific code that can be implemented in a simpler, script-based cross-platform mode (printing files, for instance); I also have platform-specific code that expands functionality already provided by Tcl/Tk's core API's (application scripting) without much benefit. In deciding to keep or abandon native API's, I am going to look at whether the functionality is essential to the app and if it cannot be achieved in a similar way using a simpler approach. If the answer to both questions is yes, then the native functionally will stay. Otherwise, the functionality will be removed or re-implemented.

You may wonder about the business case for open-sourcing my code. Will this allow anyone to download my apps for free without paying for them? Well, in theory, yes; anyone can download and patch my apps for their needs. But building my apps is a non-trivial process--most people are not software developers--and I don't expect that many people are going to be inclined to bang away at the steps needed to patch and build my apps. There is still a huge convenience factor in providing an easy-to-install package from the get-go. Given that I am not currently seeing huge sales on the Mac, the upside to expanding my distribution to other platforms far exceeds the risk I am undertaking by open-sourcing my code.

Concurrent with this change, I plan to phase out my involvement with the Mac App Store. Like many other developers have found, my sales in the app store have dwindled to almost nothing, and the increasing technical restrictions on apps deployed there have simply become too large a headache to deal with. (See this discussion for more detail.) I still plan to remain a paid member of Apple's developer network, because of other benefits it provides (documentation, code-signing certificate, etc.). But I also plan to pursue other platforms as well.

[/business] permanent link