Here is another example of why I love working with open source software and its communities. Last Thursday, one of my team members reached out and asked for advice with regards to a build issue he was observing. We use Maven & Tycho at Tasktop for building almost all of our products. One of its unique features is automated stable versioning based on source code history and dependencies.
Turns out that there was a shortcoming in the implementation with regards to building an aggregated version based on component dependencies. After finding out, I opened a defect report, prepared a patch and posted to the mailing list for awareness and getting feedback on Friday. This took me less then an hour of my time. By Monday – only 72 hours later – the patch was accepted and merged into the main code base, unblocking my colleague.
- Discover the root cause.
- File defect report
- Prepare patch
- Communicate about change and collect feedback
- Cross fingers – or – hold thumbs.
In my opinion, the key criteria for such a change being successful is the patch size. Yes, I could have added configurability to the change and that would have increased the patch size. The larger a change is, the more time committers need to set aside for understanding and reviewing a change. It’s about the minimal viable solution – keeping things simple. Don’t overwhelm committers with your first change.
Well, and it pays off going to conferences and having a beer or two with project committers.
You get something like this:
Nachträgliche manuelle Umbuchungen sind technisch völlig ausgeschlossen, da ein zentrales Rechenzentrum mit Warenwirtschaftssystemanbindung sämtliche Buchungsvorgänge vollautomatisch steuert.
Or in English:
Manual modifications afterwards are technically absolutely impossible, because we have a central data center with ERP system integration which controls every booking totally automated.
We don’t have control over our software. Sorry folks, you lost.
I get this sentence whenever I want to make a change to an already place order. For example, an item is on backorder and it just takes too long but there is a similar one available on stock. Actually I would expect the system to detect this before I place an order but that’s another story.
#onlineshop #eibmarkt #fail 🙁
I came across this couple of times before and I always wanted to blog about it. In my daily work life I see many developers which just don’t get Open Source. For example, some discover issues in libraries they use. But they don’t fix them. They don’t even inform the maintainers of a library. Yet others have a great new use-case to address. Again, the library doesn’t support it. Thus, they write a great deal of new code to address their issue and eventually run into new ones (for example, see this thread).
But it’s that darn simple!
- Checkout the library from source. You can use a well known tag/branch for this.
- Get in touch with the maintainers and implement your modifications.
- Build and release your modified version until a new official release is available.
There is a nice SpringSource blog about their plans for building OSGi applications. Actually, it’s more an advertisment for their tool called bundlor which basically has the same purpose as bnd but is implemented in a different way.
There is one point in the blog the I don’t like at all. It’s yet again I hear the myth about automatically generating OSGi bundles from 3rd party libraries and how successful it is used in the SpringSource bundle repository. Folks, it might work for one 3rd party library but it will never work in an automated way for all 3rd party libraries. There are just too many issues around OSGi-fying 3rd party libs which need to be addressed carefully. If the library deals with class loading you might be out of luck no matter how great your generated manifests look like. You need to modify your source code and/or patch the 3rd party library to make it work correctly. Even better, sometimes there are multiple ways to convert a 3rd party library into an OSGi bundle. A stubborn one-to-one conversion process cannot incorporate that. It may depend on your requirements and preferences.
The process is not finished with generating manifests. Be aware that this can cause broken bundles. Those issues are fixable. But this example shows that every library requires careful attention.
I’m hosting some projects over at Google Code. As part of the project setup you can select a license from a drop-down list. Apparently, the list is limited to eight licenses. The EPL is not it this list.
The Google Help Center says:
We’d like to see projects standardize on the most popular, time-tested ones. The selected licenses offer diversity to meet most developer needs.
The question to add EPL to that list came up a couple of times. In one of the discussions Greg Stein said:
[…] the Eclipse Public License has not really been adopted by the wider open source community. It is mostly being used just by one smallish corner: projects based on or around Eclipse.
That sucks, eh? But it gets worse.
I tried to make a reply using the web interface in that thread to make a comment about the license drop-down. For some reason it did not go to the list but directly to Greg. His response shocked me a little bit.
We only allow those eight licenses. If we find projects that are not licensed as described by the dropdown, then we will remove them.
Ok, back to SourceForge I guess. 😐