Opensource maskerkeying project proposal - restarted

[DaveAG]

I was just having a look at your idea, I like it very much but am a bit concerned by the inherent cost barriers in R&D for an open source lock. It does have one advantage of course that whilst everyone is allowed to copy the lock, costs can be recouped as everyone distributing the lock would have to charge something. Bytes are free, brass isn't!

If anyone is interested in what I meant by requirements for the Open-source Master-key project, have a look at http://dev.tydecho.co.uk/seg03_require.doc (Warning 2Mb file hosted on an ADSL connection). This is the document we had to submit last year as part of our software engineering module. Basically there is an introduction, requirements with input and output specifications listed, priorities and then also some UML diagrams showing how the requirements link together into control flow.

The idea is that by formally specifiying requirements a working implementation can be got "to market" fairly quickly with features that miss the requirements document being held back for version 2. The way they are specified and tied together then leads on very naturally to designing the system.

Once the system is specified it can be designed. Once designed it can be coded. For a 20 week project we only spent 3 weeks coding. I'd hope this project could move a little faster than that (as after all in an academic context a lot of the stuff was so to demonstrate we could, rather than because we should)

The biggest risk I see in any opensource project is collaboration. The more coders you have the more gets done *if* they work well together. That is a very big if as the book "The mythical man-month" explains.

Ok, I'll stop revising my software engineering in this post now.

[Schuyler]

dave - I'm down with you being lead, after dreamhost has pulled out of it's current network issue, I'll install subversion, if that works for you. Or activecollab, or both. Whatever.

[mh]

Bytes are free, brass isn't!

I'm thinking more of steel than brass but you are right.

The cost of R&D in a commercial environment is usually quite high for SW engineering, compared to the HW material, but indeed, in open source collaboration, the SW part is free, and the hardware can become an obstacle... Strange inversion...

As the masterkeying software can run on normal PCs, that shouldn't be a problem.
And for The Open Source Lock, it just requires people who build & pay for the stuff because they like to do that as a hobby (like me for example )

The biggest risk I see in any opensource project is collaboration. The more coders you have the more gets done *if* they work well together. That is a very big if as the book "The mythical man-month" explains.

Yep.
But at least you don't have the issue of too many project managers. From my experience with SW engineering (in a mobile phones company that recently went bankrupt), one big problem arises if everybody likes to manage their small project rather than to code & debug themselves.
But I believe people who contribute to open source projects are not like that.


On the topic itself:
How large do you estimate that project?
Is there a commercial example SW that roughly shows the features you want to have,
and how many months would one SW engineer work on that?

Cheers,
mh

[Schuyler]

Whitehat, that talk was awesome, I actually ended up writing to the presenters.

OK: I've got no problem with this being a web app or a standalone.

Benefits to the web app:

1. Should remove any technological bar to entry if it's designed to support any modern web browser.
2. Shouldn't have to worry about translation issues between different operating systems.(though arguably this could be solved by writing it in Java or something comparable)
3. If I'm not mistaken, it would allow us to better log errors, if only ensuring that we're informed every time it breaks, whereas with the standalone we might miss some strange error that one, or only a few, users have managed to reproduce.

Benefits to the standalone:

1. Seems like it would be easier for different people to work on it, but that's an entirely uninformed assumption.
2. Could be physically distributed at events like DEFCON and HOPE which would be sweet.
3. Would put any processing in the domain of the user, rather than taxing our server. Considering the potential uses of this project, it seems like it could prove to be quite taxing. But that's fairly far thinking.

The two biggest ones for me are the first 2 points for the web app, and the second point for the standalone.

Presently I'm leaning toward the Webapp.

Other opinions?

[DaveAG]

SVN would be great.

If people are willing to offer time for this, be it as a coder, tester, artist etc can they post on here saying so, along with their experiences with various languages etc.

Also, (and I'm looking at Raccoon here), we'll need someone to go over the indepth processes behind masterkeying, i.e. developing the algorithms. Even if you can't code, a step by step walkthrough can probably be converted to something more formal and mathematical, and from there to code.

To start off, my experience:

Java 4 years programming (but I feel it would be the best language for this project)
PHP 7 years programming
SQL 7 years experience
(X)HTML/CSS 7 years experience
XML/XSLT 4 years experience
C / C++ / Assembler / Perl / Haskell / Fortran -- Dabbled a little, but no real experience

Have studied the theory of software engineering for 2 years now, including a group project (Requirements document posted above), and an individual project.

The project is a bit more on the science end of computer science than most software engineering stuff is (I do a CompSci degree with some software engineering modules) but does have some ERDs, GANTT charts, and Screenshots in there to look at. Its online at http://timetool.tydecho.co.uk/report.pdf

I've also studied database theory for all three years, but to be honest many of the things a computer science student is taught have very little relevance to a project like this. Tomorrow I will be revising running sorting algorithms on massive parallel networks, not exactly a requirement for a project like this.

[DaveAG]

Raccoon, correct me where I'm wrong:

I think what you are suggesting is a system where the locksmith can set up a master-key system, then the authorised customer of that locksmith can view and keep track of keys, report losses, order replacements, and extensions to the system. Am I right?

If so, I would have thought that for security reasons, we should not be hosting the application ourselves, rather handing it out to locksmiths who then run it themselves. It would be impossible to make a system where the developers and admins couldn't (with some work) get access to names, addresses, and bittings of all the keys of all of the clients of all of the locksmiths. Even though I'm sure that everyone helping with this is honest, from a general security point of view we should treat bittings as confidential information and minimise how far it travells.

If ( and sorry if I'm sounding like a stuck record here) use Java, we could develop one core library of functions, and have the same critical code in a standalone app to start with, then extend it into a web-app when we're ready. The actual processing is the same regardless of how the information is entered and displayed.

If we do go for a webapp (either from the start or later), we should have it so that the user downloads everything they need to start the webapp going on their machine but then runs the server themselves. That way, clients confidential information doesn't go to us, with whom the client has no contract, or reason to trust.

[Raccoon]

I agree DaveG, however, most locksmiths know very little about computers and absolutely nothing about compiling and hosting software. I think there can easily be 2 parts to this project-- development as an open source project, and hosting as a company who earns revenue to further fund the project and take care of legal issues (every large-scale open source project ends up requiring lawyers at some point).

But we are getting ahead of ourselves. I recommend everyone even thinking about coding something (small or large) for master keying, first download and use at least 3 different master keying programs already on the market.

I recommend giving ProMaster 5 a try. It is the most versatile master keying software I've used, and also goes a step further to inventory your doors and lock hardware with all sorts of final handover and requisition forms. This is the type of program I would like to see become web-based.

[DaveAG]

Raccoon, I take your point, but I think there are two things to bear in mind here.

I'm not a trading locksmith, and on this site I am by no means alone in this. Even if I could find a supplier for such software (and looking at the reseller list for the UK I'm not too sure I could) I doubt I could justify the cost just to research the competition. I don't know how big the overlap is between trading locksmith and computer programmer here, but I think the way forward is for those (i.e. locksmiths) who would use the software to write down in detail what they want, with mocked up screenshots and priorities. That way the coders can build you what is required.

In the general IT industry (and maybe this is a problem I don't know) the coders have no idea about the users of the software. I might be writing software to control a factory making widgets, but have never used a widget, let alone assembled one. It is down to the "client" to make clear what they want, and it is down to the coder to ask questions and turn the client's answers into a firm set of requirements.

Also, I would guess that if this project works, we will annoy those who make a living from selling locksmith software. If we all buy copies and then they find the screens are very similar, we may be needing those lawyers sooner than you'd think. It is probably safer not to study the competition in too much detail, rather to get an idea of what we want to build, then build it.

As for having both a company to host the software and a opensource project to build it, I generally like the idea, but it is obviously for the future. It would also be possible to buy rack-mount servers and pre-install everything that you would need to just plug in power, ethernet and go, then sell these on to people. These could then be used in large institutions such as universities for in-house key management (which I believe some places still do)

[Schuyler]

Are we building this as a locksport community? or as an enterprise aimed at locksmiths?

I'm for the former, personally.

[zeke79]

The idea I had with a web app would be something where the locksmith does the work, and hand-over is done via the website to the client. The client can then manage key control and order more keys by simply visiting the site. It improves customer retention.

The problem with that is when the web host craps out two years down the road due to lack of interest, funding, or whatever you are stuck unless you work off the paper copies you printed for everything. An open source downloadable standalone application with the functional ability to export files to text or excell would be a better long term solution in my opinion. That along side a unique file type so not just anyone could access your pc and open the MK files. Of course a login to use the software would be required.

There is absolutely NO SENSE in giving the masterkey system to the business you sold it to unless you sold them the actual masterkey charts etc. You are better off to keep that as it ensures you more business in the future and it ensures you dont have to clean up after some hack came in and used the charts they downloaded to work on the system and save them a few bucks.

Always keep the masterkey system and never sell it to them unless they specify it in the contract. At that poitn you need to decide how much business you would make over a few years of servicing their system to determine what to charge them for it. When you set them up, they do not own the actual bitting arrays etc unless they request it and pay extra for it.

This also keeps the ability for you to store all of your records on your pc in your van with no internet access etc and work on the system at anytime. To me a web based system is not the best approach. A free standalone software is where it is at .

[DaveAG]

Are we building this as a locksport community? or as an enterprise aimed at locksmiths?

I'm for the former, personally.

I see no reason for the two to be mutually exclusive

The aim of the game shouldn't be commercial exploitation, however if there is money to be made from services around the periphary of the project then I see no reason that anyone involved shouldn't take the opportunity. After all, if there is money to be made someone will make money, it might as well be us, however I agree that commerical exploitation should not be the driving force behind the project.

By its very nature, the project is aimed towards locksmiths. I don't know of any hobbiest that has designed a large scale master-key system, but I think the opensource philosophy should be paramount in this. After all people are more willing to help if they feel that they are doing some good, and their work will be appreciated.

[zeke79]

DaveG,

I agree too that open source is the way to go. If at some point down the road the software becomes stale, outdated, etc then someone has the source code to take over and bring it back alive. It also guarantees that no matter what happens, being open source our file format will never become unsuported as it does when commercial software companies go belly up and you have 150 systems written in their software. There will hopefully always be someone there to take care of things since it is open source.

[Schuyler]

Are we building this as a locksport community? or as an enterprise aimed at locksmiths?

I'm for the former, personally.

By its very nature, the project is aimed towards locksmiths. I don't know of any hobbiest that has designed a large scale master-key system...

*raises hand*

Don't get me wrong, I am a hard-core libertarian capitalist, but I didn't build my own checkpin into a mortise cylinder because I thought I was filling a need or might recoup my costs, but because I wanted to know how it would work and to see if I could do it, then brought it here because I thought others might want to play around with the same concepts. Same reason I did any of my plug modding, or wrote out a moderately complex masterkey system for 75 locks in my free time.

My interest in this project is very much the same. I am specifically not interested in something that will become relied upon as a part of someone's business structure, as that puts the onus on us to keep it going beyond a certain point. My interest is in building a tool to see how well we could build it, what it would take, and to see if other people found the process or results interesting.

So, for me, the two ideas are mutually exclusive. That said? I could certainly understand if this isn't the zeitgeist, and as per the fantastic lecture that whitehat linked to, I will not allow myself to derail or poison what could be an incredible project, so if my thoughts are at odds with the prevailing ideas here, no worries, I'll still happily provide hosting for the project, but I'll likely check out a bit.

[DaveAG]

Ah yes, file formats

May I suggest we use XML of some form?

It would make it very easy for other systems to inter-operate with the project.

[DaveAG]

*raises hand*

Don't get me wrong, I am a hard-core libertarian capitalist, but I didn't build my own checkpin into a mortise cylinder because I thought I was filling a need or might recoup my costs, but because I wanted to know how it would work and to see if I could do it, then brought it here because I thought others might want to play around with the same concepts. Same reason I did any of my plug modding, or wrote out a moderately complex masterkey system for 75 locks in my free time.

My interest in this project is very much the same. I am specifically not interested in something that will become relied upon as a part of someone's business structure, as that puts the onus on us to keep it going beyond a certain point. My interest is in building a tool to see how well we could build it, what it would take, and to see if other people found the process or results interesting.

So, for me, the two ideas are mutually exclusive. That said? I could certainly understand if this isn't the zeitgeist, and as per the fantastic lecture that whitehat linked to, I will not allow myself to derail or poison what could be an incredible project, so if my thoughts are at odds with the prevailing ideas here, no worries, I'll still happily provide hosting for the project, but I'll likely check out a bit.

What I was trying to say is that a well made tool would be both interesting to develop (from a hobbiest point of view) and give a fascinating insight into masterkey systems but would also help locksmiths by its very existance.

As far as I'm concerned, developing the software to the best of our abilities would be the project's aim, but we can't help the fact that this software will be of use to locksmiths.