In July of 2011, I started a project that was later released as Wrappyr. The short-term goal was to make it easier to create cross-interpreter Python interfaces to C/C++ using ctypes. This would have been useful to the Python community, because by providing common ground between Python implementations, it would aid the rise of alternative Python implementations (like PyPy). The longer term goal was tight integration between C/C++ by not only exposing C/C++ to Python, but also the other way around. This would mean that the border between C/C++ would become very thin and would allow you to swap C/C++ and Python implementations of code without affecting any code surrounding it. All this, not through a complicated plan that will take very long to execute, but in a simple and clean way that is practically feasible in quite a short time period.

In August of that same year, I released a working albeit limited prototype to the public. The plan was to release early and often, so other people could join the process, and the community could decide how the future of the project should look. I announced my project on a mailing list and got a response from someone telling me that they have been working for a while on a project that does a large part of what Wrappyr does. The reason I couldn't find it earlier using Google was that they'll wait until their API is stable enough before releasing it to the public. The e-mail came from the Lawrence Berkeley National Laboratory, part of the U.S. dept. of Energy - a tax funded organization. The only clue about what the project does can be found at this blog post from more than a year ago. However, the projects goals, scope or any documentation are nowhere to be found yet.

Now we're left with a choice between two mentalities. On one hand you have the Open Source mentality: "release early, release often and collaborate with others" in order to get the best results possible. On the other hand you have working in a closed circle, which might accidentally work, but leaves people to wonder were all the code came from, why certain design decisions were made, etc. This is how code is born that is only maintainable by few select people and in which security vulnerabilities lurk in dark corners.

Because I like collaborating with people and think Open Source software should truly be developed in the open, I'll go down the "release early, release often and collaborate with others" road and continue developing this project. Aside from that, I think it is important to have freedom of choice, so it's nice to have alternative implementations. Meanwhile I hope that the other project will truly open soon.