3 ms·
Depends on the quality of what currently exists and the license. Typically if I find something liberally licensed that does 80-90% of what I want, I'll fork the
by gtsteve 7y ago
Depends on the quality of what currently exists and the license. Typically if I find something liberally licensed that does 80-90% of what I want, I'll fork the project, add the remainder and send a pull request back to the parent project (which is normally ignored).
Other things I take into account are how important the X is to the business. My company's product parses a very strange industry-specific file format. There are some commercial parsers and some open-source ones which do most of what I need but I opted to roll my own as working with this file format is very important and I can't risk license concerns.
Also, it might not be very nice but I don't want to help my competitors.
- analognoise 7y agoEdif?
- jdmichal 7y agoI'll strongly second your comment regarding business importance. However, I will slightly rephrase it: By expending resources to build "X", your company is now in the business of building "X". Is building "X" a business the company wants to be in? The story behind Amazon building AWS for internal needs, and then selling it externally, is an exemplar of this thought process. They were already in the AWS business... They just decided to package and sell the product to others.
- o-__-o 7y agoonly maintain a separate codebase if the feature is accepted, that way there is a finite timeline on having to be in the build business. As someone who maintained a forked openstack distribution for 5 years as a company selling openstack tooling... we wasted significant time tracking down integration bugs rather than working with the community to integrate our changes upstream