# Going Open-Source
Daniel Saidi ยท [@danielsaidi](https://twitter.com/danielsaidi)
## In this talk
* Open-source
* Private libraries
* Closed-source
* Live coding
* Discussions
## About me
* Web/js since 1995
* MSc in Media Technology
* C/C++, Python at school
* .NET, web, api at work
* iOS since 2011
## First public project
* 
## Wigbi
* Tool for ASP (Active Server Pages), later PHP
* Code generation
* PHP to JavaScript (AJAX)
* Flash plugin
* CMS
## Wigbi Learnings
* Not open-source
* Commercial product
* Commercial failure
* Built for public use
* Obfuscation, documentation
* Semver, configuration, releases etc.
## Commercial failure story time
## Today
* Open-source is everywhere
* GitHub, GitLab, BitBucket etc.
* SPM, Gradle, NPM etc.
* Markdown, Doxygen, DocC etc.
* XCFrameworks for closed-source
## Some of my projects
* (not to promote, bear with me)
* UI libs like [Sheeeeeeeeet](https://github.com/danielsaidi/Sheeeeeeeeet) and [SystemNotification](https://github.com/danielsaidi/SystemNotification)
* Mono-repos like [SwiftKit](https://github.com/danielsaidi/SwiftKit) and [SwiftUIKit](https://github.com/danielsaidi/SwiftUIKit)
* Test tools like [MockingKit](https://github.com/danielsaidi/MockingKit)
* Commercial ones like [KeyboardKit](https://github.com/KeyboardKit/KeyboardKit)
## Project updates
* New features or improvements
* Bug fixes
* User feedback
* Pull requests
* External changes (e.g. iOS, Swift)
## My work structure
* App-specific code in app target
* App-agnostic code in a framework
* App-specific framework extensions in app target
* No external dependencies in the framework
* Unit test the framework, not the app
## From app to open-source
* Convert framework to local package
* Convert local package to open-source
* Documentation with DocC
* Automate build process with Fastlane
* Demo app, code examples etc.
## App-specific frameworks
* Separate domain from app
* Reusability between targets
* More focus, less distraction
* Faster to compile
* Easier to test
## Local packages
* Cleaner separation betwen app and library
* Reusability across apps
* Increased modularity
* Easier to combine packages
* Good preparation for open-source
## Open-source
* **Better code** - since it's public
* **Communication** - what does it do?
* **Planning** - what to release, when, how?
* **Collaboration** - working with others
* **Sharing** - giving back to the community
## Why NOT open-source
* Time
* Intellectual property
* Work secrets
* High volatility
* You can still work in an open-source way
## Private projects
* Private repo or server
* Accessed with SSH instead of HTTPS
* SSH gives granular access control
* Still "open-source" when used
* Perfect for e.g. company projects
## Closed-source
* Public repo
* Pre-compiled binary, e.g. XCFramework
* Can be protected with a license
* Can use documentation, issues etc.
* Perfect for commercial projects
## Good practices
* System design, access control etc.
* Only expose the essential
* Abstractions and loose coupling
* Test, test, test
* Automate, automate, automate
## License
* Very important!
* Code without license is NOT open-source
* Without license, the author has all rights
* MIT is common, very allowing
* Others, like BSD, CPL, GPL etc.
## Conclusion
* Open-source can be very rewarding
* Can also be very demanding
* Set clear expectations on yourself
* Communicate your ambitions and intent
* Have fun!